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: email@hidden (David E. Gelhar)
- Date: 16 Oct 2008 07:33:17 -0400
--- 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