No, I meant to use packet since I was speaking in terms at the protocol level. In either case, your explanation is helpful to Bing but I fear he is new to socket level programming and will stumble with other issues as well. Your advice to use some framework is what he should follow.
Tony Romano On 6/16/11 12:29 PM, "Jens Alfke" <j...@mooseyard.com> wrote: > >On Jun 15, 2011, at 7:01 PM, Tony Romano wrote: > >> TCP does NOT guarantee you will get the WHOLE PACKET on one receive >>call. >> BEFORE you PROCESS any data, you need to know that you have ALL the >>data. >> It may work MOST of the TIME, but there are times when it won't and your >> code WILL FAIL. > >You¹re correct, but your point is a little confusing because you¹re using >the word ³packet² to mean an application-level message. Since packet¹ >already has a very specific meaning in IP networking, it¹s best to use a >different word like ³message² or ³chunk² or ³blob² or something. > >So to rephrase: Just because you sent a chunk of bytes together in one >TCP write, the recipient is not guaranteed to receive the same chunk of >bytes in a single read. It¹s quite likely that this chunk will be >combined with bytes written in other write calls, or split in half across >two reads. TCP is taking the data you give it and shoving it into buffers >in the kernel, and those buffers get split up and sent out as IP packets >according to the kernel¹s whim and some complicated windowing algorithms. >There¹s absolutely no relation between the groups of bytes you write, the >IP packets that get sent, and the groups of bytes the client reads. > >If I can once again plug my MYNetwork framework ><http://bitbucket.org/snej/mynetwork>, it includes a protocol called BLIP >that supports sending application-level messages, which can also include >metadata (key/value pairs like HTTP headers). It even supports >multiplexing multiple messages at the same time, so one huge message >won¹t clog up the socket and block others till it finishes. This stuff is >a pain in the ass to get right and I recommend using someone¹s >already-tested implementation over writing your own. (Or in other words, >³I suffered for my art so you wouldn¹t have to² :) > >Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com