[noPoll] Fixed -- Re: Websocket disconnect issues

Lun Mayo 16 10:47:08 CEST 2016

Hi Rahul,
Just let you know I've pushed some additional changes to noPoll's
github (rev 265 )
that should fix this issue. I've also added additional reg tests
(test_31, 32, 33, 34, and 35)
to simulate different stop/pause conditions and got them all working,
Let's us know if this fixes your issue,
Best Regards,
> Hello Rahul,
> 
> Received. I'll you know something,
> 
> Best Regards,
> 
> > Hello Francis,
> > 
> >  
> > 
> > My test scenario just hit the condition. The connection however got
> > broken with the following error message:
> > 
> >  
> > 
> > Failed to get next 2 bytes to read header from the wire, failed to
> > received content, shutting down id=2 the connection, errno=0 (No
> > error)
> > 
> >  
> > 
> > Since the number of bytes read was not printed, I am guessing it
> > was 1. 
> > 
> > The receive call did not actually fail but possibly delivered 1
> > byte.
> > 
> >  
> > 
> > Regards,
> > 
> >  
> > 
> > Rahul
> > 
> >  
> > 
> >  
> > 
>  
> From: Kale, Rahul 
> Sent: Friday, April 22, 2016 10:04 AM
> To: 'francis.brosnan en aspl.es'
> Cc: nopoll en lists.aspl.es
> Subject: RE: Fixed -- Re: [noPoll] Websocket disconnect issues
> 
> 
>  
>  
> 
> Hello,
> 
>  
> 
> I am currently running the test scenario but the failure condition
> has not happened yet
> 
> in the first 12 hours. Sometimes it takes 2-3 days to reproduce. I
> will let you
> 
> know when it happens next.
> 
>  
> 
> Besides the SSL twist, even for plain TCP connection I believe this
> situation can occur.
> 
> Due to maximum transmission unit (MTU) limitations the sender can
> break up messages
> 
> at arbitrary byte boundaries. If the receiver is slow to read, or if
> the network
> 
> bandwidth is limited, a fast sender will accumulate data to send. It
> will send
> 
> piled up data (multiple websocket messages in our case) in chunks of
> MTU size
> 
> and end up breaking messages at arbitrary byte boundaries.
> 
>  
> 
> You are totally correct in saying that the OS will not deliver bytes
> collected
> 
> from the wire to user space in a broken fashion. But the OS on the
> sender can put the
> 
> bytes on the wire in arbitrary pieces (TCP segments) depending on
> transient network conditions, 
> 
> acks received, TCP sliding window size, round trip time, MTU size
> etc. 
> 
> I am no expert at this, but the few TCP protocols I have implemented
> I have always had to account for this
> 
> before the application achieved 24/7 reliability.  For non-blocking
> sockets this is not trivial to achieve.
> 
> For blocking sockets, it is much easier.
> 
>  
> 
> I am glad that you are considering fixing this properly. It will make
> the nopoll
> 
> library more robust for everyone :)
> 
>  
> 
>  
> 
> Thanks,
> 
>  
> 
> Rahul
> 
>  
> 
>  
> From: Francis Brosnan Blázquez [mailto:francis.brosnan en aspl.es] 
> Sent: Friday, April 22, 2016 5:52 AM
> To: Kale, Rahul
> Cc: nopoll en lists.aspl.es
> Subject: Re: Fixed -- Re: [noPoll] Websocket disconnect issues
> 
> 
>  
>  
> 
> Hi Raul,
> 
> It is going to take us a bit to deeply resolve the issue and
> more precisely, to support websockets peers sending byte
> by byte important parts of the headers that should be received
> at once...
> 
> In any case, I was wondering if you did have time to check
> latest modifications... did them resolve the issue? Is it more
> stable your test case?
> 
> Please, let us know how the latest changes performs in your
> scenario,
> 
> Best Regards,
> 
> 
> 
> Hello,
> 
> Thanks very much for your excellent analysis. It is indeed surprising
> that such a small packet seems to be delivered in chunks
> occasionally. Perhaps the fact that this is via SSL is compounding
> the issue. The original websocket provided on the server side is
> proxied via Apache Webserver which adds an SSL layer.
> 
> I see that the noPoll code is already handling broken headers for the
> first two bytes and also for 4 bytes of mask. I was assuming that you
> have already faced similar issues in the past.
> 
> I really appreciate your efforts in chasing these issues and fixing
> them promptly.
> 
> Regards,
> 
> Rahul
> 
> 
> 
> 
> This message is subject to the following terms and conditions: MAIL
> DISCLAIMER<http://www.barco.com/en/maildisclaimer>
> 
>  
> 
>   
> -- 
> Francis Brosnan Blázquez - ASPL
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
>  
> http://aspl.es
> http://asplhosting.com
> http://twitter.com/aspl_es
> http://twitter.com/asplhosting
>  
> AVISO LEGAL
>  
> Este mensaje se dirige exclusivamente a su destinatario. Los datos
> incluidos en el presente correo son confidenciales y sometidos a
> secreto
> profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes.
> Si
> usted no lo es y lo ha recibido por error o tiene conocimiento del
> mismo
> por cualquier motivo, le rogamos que nos lo comunique por este medio
> y
> proceda a destruirlo o borrarlo.
>  
> En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> diciembre, de Protección de Datos de Carácter Personal, le informamos
> de
> que sus datos de carácter personal, recogidos de fuentes accesibles
> al
> público o datos que usted nos ha facilitado previamente, proceden de
> bases de datos propiedad de Advanced Software Production Line, S.L.
> (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y oposición dispuestos en la mencionada
> Ley
> Orgánica, notificándolo por escrito a:
> ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> Henares (Madrid).
> 
>  
> 
> 
>  
> This message is subject to the following terms and conditions: MAIL
> DISCLAIMER
> _______________________________________________
> noPoll mailing list
> noPoll en lists.aspl.es
> http://lists.aspl.es/cgi-bin/mailman/listinfo/nopoll
>  
>  
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.aspl.es/pipermail/nopoll/attachments/20160516/813f17bb/attachment.html>