On Sun, Jan 11, 2009 at 1:42 PM, Erich <[email protected]> wrote: > The way I read it, multiple messages per packet is not explicitly > allowed or denied. Now, my understanding of tcp (and network > probgramming...) is that higher level layers shouldn't rely on per > packet stuff, but that's not always the case.
Practically the only difference from server's point of view is how many bytes come in from a single read() call. Beanstalkd knows what to do if it reads more than one command at a time. (This can happen if two requests are in one packet or if two packets arrive before a read() call.) Clients can use TCP_CORK or something similar to affect how commands get split into packets, if they want the best performance. > I assumed it would > work just fine, but being a pythonista, I like explicit :) Yeah. The relevant passage is, "For each connection, the server processes commands serially in the order in which they were received and sends responses in the same order". This statement has no qualifications, and it applies regardless of how the bytes of those commands are partitioned into packets or the timing of those packets. I added that sentence after a discussion on the mailing list a while ago on this same point, but clearly the description still doesn't go far enough. kr --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
