Hi ! I am very new at Twisted. What i am trying to achieve is a simple web service using basic HTTTP GET and POST requests. My big requirement is being able to detect when the connection is closed client side. Bottom line being : i want to know that each GET or POST result has been successfully or not sent to the client. I could not managed to do that using WSGI. Is there way to try: catch sockets exception using Twisted or should i go the async way and use notifyFinish() and friends ?
Thanks in advance !
Seb
On Mon, May 10, 2010 at 4:44 PM, Sebastien PASTOR sebastien.pastor@gmx.com wrote:
Hi ! I am very new at Twisted. What i am trying to achieve is a simple web service using basic HTTTP GET and POST requests. My big requirement is being able to detect when the connection is closed client side. Bottom line being : i want to know that each GET or POST result has been successfully or not sent to the client. I could not managed to do that using WSGI. Is there way to try: catch sockets exception using Twisted or should i go the async way and use notifyFinish() and friends ?
Thanks in advance !
Seb
HTTP is stateless, you have no way of knowing if the client closed the connection
Take a look at this, for some ideas http://en.wikipedia.org/wiki/Comet_%28programming%29
hth
Graeme
Thanks graeme,
Yup, i know HTTP is stateless.. My question is more how to get the exception from a Resource object when trying to write to a closed socket.
cheers
Seb
On Mon, May 10, 2010 at 04:00:03PM +0200, Graeme Glass wrote:
On Mon, May 10, 2010 at 4:44 PM, Sebastien PASTOR sebastien.pastor@gmx.com wrote:
Hi ! I am very new at Twisted. What i am trying to achieve is a simple web service using basic HTTTP GET and POST requests. My big requirement is being able to detect when the connection is closed client side. Bottom line being : i want to know that each GET or POST result has been successfully or not sent to the client. I could not managed to do that using WSGI. Is there way to try: catch sockets exception using Twisted or should i go the async way and use notifyFinish() and friends ?
Thanks in advance !
Seb
HTTP is stateless, you have no way of knowing if the client closed the connection
Take a look at this, for some ideas http://en.wikipedia.org/wiki/Comet_%28programming%29
hth
Graeme
Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
On 10/05/10 16:04, Sebastien PASTOR wrote:
Thanks graeme,
Yup, i know HTTP is stateless.. My question is more how to get the exception from a Resource object when trying to write to a closed socket.
There's a request.notifyFinish method somewhere in there, which returns a deferred that callback's on success and errback's on failure.
Thanks Phil,
I managed to be notified when the connection is cleanly closed by the client (ie: browser is stop or close window). But i could not handle non-clean connection closure (ie: when wifi goes down client side for instance). request.finish() does not event raise any error. ... I am a bit stuck here. .. any ideas ?
Thanks
Seb
On Mon, May 10, 2010 at 03:25:33PM +0100, Phil Mayers wrote:
On 10/05/10 16:04, Sebastien PASTOR wrote:
Thanks graeme,
Yup, i know HTTP is stateless.. My question is more how to get the exception from a Resource object when trying to write to a closed socket.
There's a request.notifyFinish method somewhere in there, which returns a deferred that callback's on success and errback's on failure.
Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
On 11/05/10 13:23, Sebastien PASTOR wrote:
Thanks Phil,
I managed to be notified when the connection is cleanly closed by the client (ie: browser is stop or close window). But i could not handle non-clean connection closure (ie: when wifi goes down client side for instance). request.finish() does not event raise any error. ... I am a bit stuck here. .. any ideas ?
I'm not sure I follow.
Have a look at this to make sure you're using it properly:
It looks to me that this is what i am doin ... I really might be doing something wrong here but can t see what. The only difference with the livejournal's code is that i am trying to run a blocking code so i am doing a threads.deferToThread instead of doing a callLater. To test the connection lost, client side i am disabling the wifi while the server is blocking (sleeping). At the end of the blocking code: request.write() and finish() are done as if the connection was available and my ErrCallBack is not called.
I hope i am clear... in attachment the code i am using
Thanks for your time
Seb
On Tue, May 11, 2010 at 12:54:40PM +0100, Phil Mayers wrote:
On 11/05/10 13:23, Sebastien PASTOR wrote:
Thanks Phil,
I managed to be notified when the connection is cleanly closed by the client (ie: browser is stop or close window). But i could not handle non-clean connection closure (ie: when wifi goes down client side for instance). request.finish() does not event raise any error. ... I am a bit stuck here. .. any ideas ?
I'm not sure I follow.
Have a look at this to make sure you're using it properly:
http://jcalderone.livejournal.com/50890.html
Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
On 11/05/10 14:46, Sebastien PASTOR wrote:
It looks to me that this is what i am doin ... I really might be doing something wrong here but can t see what. The only difference with the livejournal's code is that i am trying to run a blocking code so i am doing a threads.deferToThread instead of doing a callLater. To test the connection lost, client side i am disabling the wifi while the server is blocking (sleeping). At the end of the blocking code: request.write() and finish() are done as if the connection was available and my ErrCallBack is not called.
If you're disabling the wi-fi, then you'll have to wait until the TCP connection timeout occurs. This might be a long, long time, or possibly never, if keepalives aren't enabled.
You could try enabling aggressive values for TCP keepalives on the underlying TCP connection, but I'm not sure that's advisable.
-
Graeme Glass -
Phil Mayers -
Sebastien PASTOR