User-agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
Mark Gilbert wrote:
Before I rework this code to deal with this, I wanted to get any general
guidelines on the best way to handle exchange of larger packets of data
via sockets.
Any particular tricks ? pitfalls ?
Firstly, are you using a stream (semi-continuous flow of information) or
datagram (explicit discrete messages) model? Are you using TCP or UDP?
The stream model generally uses TCP, which includes a bunch of overhead to
ensure reliable, in-order delivery and to avoid link saturation. The
datagram model can use either TCP or UDP, but UDP has historically had this
model in mind. UDP simply attempts to deliver single "packets" of data,
and doesn't have the same reliability model that TCP does.
Sending a 30k "datagram" is interesting, since you will inevitably suffer
fragmentation. A standard ethernet supports discrete packets of only ~1500
bytes or less. As such, large datagrams must be split up into smaller
packets for transmission, and then reassembled at the destination.
TCP avoids this by simply buffering everything in a large sequential buffer
and peeling off appropriate sized chunks for packetisation at an
appropriate rate to avoid losing packets. UDP doesn't do this, so it
simply partitions the datagram, sends a rush of packets, and hopes they all
get through. If some don't then the packet cannot be reassembled and the
whole packet is discarded.
In particular, whereas previously I could read 1 byte blocking, then
> continue reading until 'read' returned-1 (which would be the end of the
> reply), I now see a return of -1 part way through the 30k reply, and it
> picks up again later.
This is perfectly normal. 'read' only returns what has currently been
received, and delivering 30kb of data is not atomic. It takes a little bit
of time for the system to tell your app to respond to delivered data, so
you may get more than one packet in the receive buffer before your app gets
a chance to read it.
You also need to be careful with 'read' and datagrams, since it deals in
data, not messages. Even with small packets, it's quite possible to have
more than one in the buffer, and if you use a big enough destination buffer
then read could slurp them all up in one hit. If you really need
per-packet / datagram handling, you should use 'recvfrom' instead.
--
Andrew White
--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
