Swirling perspective on server broker side

Question

I use twisted Perspective Broker to talk between client and server. The client requests the remote method "remote_ssh" from the server. This forces the PB server to initiate an SSH connection using the Paramiko SSH library and retrieve the configuration from the remote device.

All this works fine, but when I do this for several remote devices, I see the following behavior: the Perspective Broker client will send all requests to the PB server. Then the PB server will execute these requests one by one (this is normal), but it will not return ANY results until they are completed.

Here is the corresponding PB server code:

class RMethods(pb.Root): def remote_ssh(self, aDict): self.login('SSH', aDict) # Login to remote device response = self.aSSH.retrieve() # Retrieve the config self.aSSH.close() return response if __name__ == "__main__": reactor.listenTCP(1885, pb.PBServerFactory(RMethods())) reactor.run() 

From a look at the system level information (TCPDump and netstat), I see the following (suppose 5 remote method calls):

Call remote_ssh from PB Client on PB Server so that five remote devices happen at about the same time

  self.login device 1 self.aSSH.retrieve() device 1 self.aSSH.close() device 1 self.login device 2 self.aSSH.retrieve() device 2 self.aSSH.close() device 2 ... self.login device 5 self.aSSH.retrieve() device 5 self.aSSH.close() device 5 return results for all 5 devices 

I don’t understand why it is waiting for the results to return (that is, why it waited for Device5 to complete before the results for device1 are returned).

Answer 1

This is because replies cannot be sent until the reactor has a chance to start. If all five requests arrive at about the same time, then the reactor may wake up once and notice all five of them at the same time. It will send all five of them to the PB server. The remote_ssh method will serve one of them, blocking all the time. When this is done, the answer will (almost certainly) be queued. Then the remote_ssh method will serve the next one and this response will be queued. And so on, until all requests are processed. Then the reactor will complete sending the initial group of 5 events and move on to the next. When it moves, it will find the data ready to be sent and will start sending it.

In other words, blocking prevents the operation of the reactor, including preventing it from sending output data that is ready to be sent.

Instead, you can try using Twisted Conch as your SSH client, which can allow you to work with SSH without blocking, or you can try using existing SSH code with threads (provided that it can be made thread safe) or multiple processes.