Newbie question : client connection lost
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.
participants (3)
-
Graeme Glass -
Phil Mayers -
Sebastien PASTOR