[noPoll] [Amarisoft] Patch proposal
Emmanuel Puig
emmanuel.puig en amarisoft.com
Mie Feb 15 09:33:04 CET 2017
Hi,
I confirm that what Rahul faced is exactly the same as I face.
The easiest way to reproduce is to send "big" amount of data (> 32K). In
such situation, the TCP window of the socket is full and a fragment will
be received after multiple call to recv on the socket.
This leads to multiple call of nopoll_conn_get_msg and in particular,
for the last fragment where is_final is set for each call of
nopoll_conn_get_msg
I don't see any problem that nopoll_conn_get_msg does not match exact
web socket level fragmentation.
The only problem is to be sure to detect end of transfer, which is not
possible in this situation
In the code, has_fin and is_fragment are reflecting the web socket state
but not no_poll abstraction. This is the case for fragment (cf
nopoll_msg_is_fragment), may be the case for fin, what explains my
(very) simple patch.
NB: you may also reproduce the issue with a "slow" connection
I often use nodejs + websocket plugin to test my code
Best regards,
--
Emmanuel Puig
Amarisoft R&D Manager
On 02/14/2017 09:06 PM, Kale, Rahul wrote:
>
> Hello Francis,
>
> Thanks for the quick response!
>
> I was actually referring to my earlier posts in June 2016.
>
> (the gethostbyname() issue was in October 2016 which is now resolved).
>
> Back in June I had a series of posts (some of them related to final
> flag) titled:
>
> [noPoll] Stress Test -- Client connection timeouts Kale, Rahul
>
> [noPoll] Stress Test -- Client connection timeouts Kale, Rahul
>
> [noPoll] Stress Test -- Final Flag after calling nopoll_conn_get_msg
> Kale, Rahul
>
> [noPoll] Stress Test -- Final Flag after calling nopoll_conn_get_msg
> Kale, Rahul
>
> [noPoll] Stress Test -- Final Flag after calling nopoll_conn_get_msg
> Kale, Rahul
>
> [noPoll] Websocket diconnect issues -- stress test Kale, Rahul
>
> Regards,
>
> Rahul
>
> *From:*Francis Brosnan Blázquez [mailto:francis.brosnan at aspl.es]
> *Sent:* Tuesday, February 14, 2017 10:36 AM
> *To:* Kale, Rahul
> *Cc:* Emmanuel Puig; nopoll at lists.aspl.es
> *Subject:* Re: [noPoll] [Amarisoft] Patch proposal
>
> Hello Rahul,
>
> Also, please refer to my posts back in June 2016 to the mailing list
> regarding various issues with the final flag.
>
>
> About this issue, I remember you found out that DNS resolution API
> what the cause of your stress test problems:
>
> /http://lists.aspl.es/pipermail/nopoll/2016-October/000156.html/
>
> /I have narrowed down the cause of intermittent failures in our stress/
> /test cases to the use of gethostbyname() in noPoll library./
> /This function is not thread safe under Linux (possibly other
> platforms too)./
>
> I replied you that we did an update that included this change
> (gethostbyname
> replacement):
>
> /http://lists.aspl.es/pipermail/nopoll/2016-November/000157.html/
>
> /At the same time, that code update already replaced gethostbyname/
> /by getaddrinfo, so next stable release, or current github stable release/
> /(305) [1] should also fix your issue./
>
> However, I didn't receive any reply about the matter. Maybe you can
> clarify
> if the issue persisted (even having gethostbyname replaced) and how this
> relates to Emmanuel's patch,
>
> Best Regards,
>
>
>
>
> Regards,
>
> Rahul
>
> On Feb 14, 2017 6:43 AM, Emmanuel Puig
> <emmanuel.puig at amarisoft.com <mailto:emmanuel.puig at amarisoft.com>>
> wrote:
>
> Hi,
>
>
> I'm Emmanuel Puig from Amarisoft company and we are using your
> stack for
> WebSocket.
> I've reported a patch few years ago that you had integrated.
>
> Here is another patch proposal for a bug we encounter with
> huge amount
> of transferred data.
>
> At the end of a transfer, if the final fragment is received
> from socket
> in chunks, each chunk is tagged as final and fragment
> (nopoll_msg_is_final/nopoll_msg_is_fragment)
> This forbids to detect the exact end of the message.
>
> The patch avoids to set final when if there are remaining data.
>
> Best regards,
>
> _______________________________________________
>
> noPoll mailing list
>
> noPoll at lists.aspl.es <mailto:noPoll at lists.aspl.es>
>
> http://lists.aspl.es/cgi-bin/mailman/listinfo/nopoll
>
> -- 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 <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 <http://www.barco.com/en/maildisclaimer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.aspl.es/pipermail/nopoll/attachments/20170215/717dbe5b/attachment.html>
Más información sobre la lista de distribución noPoll