[Twisted-Python] Question about a custom byte oriented TCP protocol

Hi, I'm trying to use twisted to talk to an existing system that uses a byte oriented protocol stuffed inside a TCP packet. I have implemented this using the IntNStringReceiver modified to look at some bytes to calculate the size of the string to receive. For simple test cases where I send a single packet this works but if I send multiple requests they all end up in the same tcp packet which the existing server doesn't like. How can I ensure that only a single command\string is sent per tcp packet? I tried TCP No Delay but that didn't seem to help Regards, Michael

On Tue, 2 Jun 2009 16:09:00 +0100, Michael Thompson <michaelnt@gmail.com> wrote:
In general, this is impossible. TCP does not work that way. For a specific application, you may be able to achieve this by only sending another message after you *know* the server has received an earlier message. You can probably achieve this if the server sends you back an acknowledgment of each message - then you wait to receive an acknowledgment before sending another message. However, the purpose of IntNStringReceiver - arguably the sole purpose - is to provide a "framing" layer for the messages being exchanged with it. This framing layer exists so that if messages do get squished together (or broken up, as may also happen) by TCP, they can still be properly interpreted. If the server breaks when multiple commands/strings are received by it at once, then perhaps it is broken and needs to be fixed. Jean-Paul

On Tue, 2 Jun 2009 16:09:00 +0100, Michael Thompson <michaelnt@gmail.com> wrote:
In general, this is impossible. TCP does not work that way. For a specific application, you may be able to achieve this by only sending another message after you *know* the server has received an earlier message. You can probably achieve this if the server sends you back an acknowledgment of each message - then you wait to receive an acknowledgment before sending another message. However, the purpose of IntNStringReceiver - arguably the sole purpose - is to provide a "framing" layer for the messages being exchanged with it. This framing layer exists so that if messages do get squished together (or broken up, as may also happen) by TCP, they can still be properly interpreted. If the server breaks when multiple commands/strings are received by it at once, then perhaps it is broken and needs to be fixed. Jean-Paul
participants (2)
-
Jean-Paul Calderone
-
Michael Thompson