site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)

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.

-- 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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 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. This email sent to site_archiver@lists.apple.com