Re: Force packetise and interesting phenomena with two listening sockets
Re: Force packetise and interesting phenomena with two listening sockets
- Subject: Re: Force packetise and interesting phenomena with two listening sockets
- From: Liwei <email@hidden>
- Date: Thu, 16 Oct 2008 20:00:44 +0800
Thanks for the reply!
Ahh, that explains it!
Well, I guess I'm too lazy to devise and write a protocol that allows
me to know clearly when each "packet" of data arrives. I'm writing a
sort of logging application (which is complicated by the fact that
each data entry can be only different length) so I need to know when
each data entry starts and ends, so I thought if each send() or
CFWriteStreamWrite() generates one result (one packet, or if its too
long, over multiple fragments) on the other side, I would only need a
fixed header, footer and checksum to do my stuff.
I guess I'll have to be more hardworking then!
2008/10/16 David E. Gelhar <email@hidden>:
> --- Liwei <email@hidden> wrote:
> I wonder how I can force my data to be sent with as a single packet
> under TCP with each call to either send() or CFWriteStreamWrite()
> instead of bunching them up into multiple big packets. It seems to be
> able to do that under UDP but not TCP.
> --- end of quote ---
>
> In general, your application can't control how the TCP layer decides to
> packetise your data. Packet size is going to depend on a lot of things,
> (potentially) including the maximum segment size of your network link, the
> receiving machine's advertised receive window, the TCP flow
> control/retransmission algorithms, and so forth.
>
> Even if you could control this on the sending side, similar constraints
> apply on the receive side: a recv() call on a TCP connection is going to
> give you a chunk of bytes, but there's no way for you to tell if those bytes
> arrived in one packet or 10 -- packet boundaries are simply not part of the
> TCP interface.
>
> This is one of the differences between TCP and UDP. In TCP, you're dealing
> with a stream of bytes, in UDP you're working with datagrams (packets). TCP
> promises to deliver those bytes in order, without loss or duplication,
> automatically taking care of retransmission and flow control, but doesn't
> give you control over packet boundaries.
>
> I guess the question is, why do you care how many packets TCP sends your
> data in?
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden