views:

192

answers:

1

Hello,

I am coding a python (2.6) interface to a web service. I need to communicate via http so that :

  • Cookies are handled automatically,
  • The requests are asynchronous,
  • The order in which the requests are sent is respected (the order in which the responses to these requests are received does not matter).

I have tried what could be easily derived from the build-in libraries, facing different problems :

  • Using httplib and urllib2, the requests are synchronous unless I use thread, in which case the order is not guaranteed to be respected,
  • Using asyncore, there was no library to automatically deal with cookies send by the web service.

After some googling, it seems that there are many examples of python scripts or libraries that match 2 out of the 3 criteria, but not the 3 of them. I am thinking of reading through the cookielib sources and adapting what I need of it to asyncore (or only to my application in a ad hoc manner), but it seems strange that nothing like this exists yet, as I guess I am not the only one interested. If anyone knows of pointers about this problem, it would be greatly appreciated.

Thank you.

Edit to clarify :

What I am doing is a local proxy that interfaces my IRC client with a webchat. It creates a socket that listens to IRC connections, then upon receiving one, it logs in the webchat via http. I don't have access to the behaviour of the webchat, and it uses cookies for session IDs. When client sends several IRC requests to my python proxy, I have to forward them to the webchat's server via http and with cookies. I also want to do this asynchronously (I don't want to wait for the http response before I send the next request), and currently what happens is that the order in which the http requests are sent is not the order in which the IRC commands were received.

I hope this clarifies the question, and I will of course detail more if it doesn't.

+1  A: 

Using httplib and urllib2, the requests are synchronous unless I use thread, in which case the order is not guaranteed to be respected

How would you know that the order has been respected unless you get your response back from the first connection before you send the response to the second connection? After all, you don't care what order the responses come in, so it's very possible that the responses come back in the order you expect but that your requests were processed in the wrong order!

The only way you can guarantee the ordering is by waiting for confirmation that the first request has successfully arrived (eg. you start receiving the response for it) before beginning the second request. You can do this by not launching the second thread until you reach the response handling part of the first thread.

Kylotan
Thank you very much for your answer. I still have a few concerns :Doesn't HTTP guarantee that the packets are treated by the receiver in the order they were sent (as it is built on TCP and as TCP does)? In that case, at the HTTP level, all I have to do is to send synchronously, and receive asynchronously. Am I assuming something wrong?Also, I can indeed thread only the response handling part, but IRC sometimes sends many commands at once: it would make their processing longer by roughly as many pings.(Note that I edited the question with more about what I am trying to achieve)
Lay
TCP does guarantee that data is kept in order for a given connection, but when you make multiple HTTP requests, you're typically not making them with the same connection so the guarantee becomes irrelevant to your case. In particular you can't split the request and the response up the way that you like because you have no guarantee that the request has actually been processed, even if you sent the whole thing, until you see the response. I don't think your asynchronicity requirement is compatible with your ordering requirement, basically.
Kylotan
Yes, you are right, the assumption that the order would be kept in HTTP just because it is on TCP was bad. I will check the last option that I have in mind (a way to send several IRC commands via a single HTTP request, if the web interface I am connecting to permits it), and if it does not work I will have to make a choice (which might be an intermediate choice, like handling in a different manner the commands for which the order is important and the ones for which it is not). Thank you again for your helpful answers.
Lay