Twisted transport.write

Question

Is there any way to force self.transport.write(response) to write immediately to its connection so that the next call to self.transport.write(response) does not get buffered into the same call.

We have a client with legacy software we cannot amend, that reads for the 1st request and then starts reading again, and the problem I have is twisted joins the two writes together which breaks the client any ideas i have tried looking into deferreds but i don't think it will help in this case

Example:

self.transport.write("|123|") # amount of messages to follow 
a loop to generate next message
self.transport.write("|message 1 text here|")

Expected:

|123|
|message 1 text here|

Result:

|123||message 1 text here|

Answer 1

I was having a somewhat related problem using down level Python 2.6. The host I was talking to was expecting a single ACK character, and THEN a separate data buffer, and they all came at once. On top of this, it was a TLS connection. However, if you reference the socket DIRECTLY, you can invoke a sendall() as:

self.transport.write(Global.ACK)

to:

self.transport.getHandle().sendall(Global.ACK)

... and that should work. This does not seem to be a problem on Python 2.7 with Twisted on X86, just Python 2.6 on a SHEEVAPlug ARM processor.

Answer 2

Can you tell which transport you are using. For most implementations, This is the typical approach :

 def write(self, data):
        if data:
            if self.writeInProgress:
                self.outQueue.append(data)
            else:
                ....

Based on the details the behavior of write function can be changed to do as desired.

Answer 3

Maybe You can register your protocol as a pull producer to the transport

self.transport.registerProducer(self, False)

and then create a write method in your protocol that has it's job buffering the data until the transport call your protocol resumeProducing method to fetch the data one by one.

def write(self, data):
    self._buffers.append(data)

def resumeProducing(self):
    data = self._buffers.pop()
    self.transport.write(data)

Answer 4

Put a relatively large delay (10 seconds) between writes. This will be the only possible solution. Because if the recipient is so badly written by people who don't know what TCP is and how to use it, you can hardly do anything (other than rewrite that application).