On Monday, July 14, 2014 1:03:25 PM UTC+5:30, Saúl Ibarra Corretgé wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/14/2014 07:08 AM, Ashish wrote:
> >
> > Lets say many clients are connected to a tcp server and server is
> > asynchronously sending them certain number of bytes. Now if one of
> > the clients does never read those bytes (never calls WSARecv),
> > those bytes get accumulated at server end. After that, surprisingly
> > other clients too do not receive their bytes.
> >
> > This results in never getting uv_write_cb in server code.
> >
> > If we disconnect the client (who has stopped calling WSARecv)
> > things comes on normal track, and we can see other clients
> > receiving their bytes.
> >
> > How can we proactively stop this happening? I mean is there any way
> > to detect client stopped reads. (So we can proactively disconnect
> > it before too many bytes get accumulated at server end)
> >
>
> Streams keep track of the queued bytes (stream->write_queue_size). You
> should use that to check if the client is not reading or it's too slow
> at reading and just pause the writing on your end. You can check the
> number of queued bytes in the write callbacks to decide when to resume
> sending data.
>
>
I am still struggling with this. I plan to keep track of .queued_bytes in
write callback and when it is zero then only I proceed with next uv_write.
Is it correct approach? I found two issues with this:
1. I just written 10 bytes to client. Despite client received those bytes,
.queued_bytes was still holding value 10 in callback (resulting in not to
call uv_write next time and forever)
However, stream->write_queue_size was holding zero.
2. How much maximum value shall I allow to be hold by .queued_bytes ? Is
there any guideline for optimal performance ?
> - --
> Saúl Ibarra Corretgé
> bettercallsaghul.com
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJTw4dZAAoJEEEOVVOum8BZQzMP/A7FV/Qz+G5Cim82TqZM2EcF
> hjO6KWU7VarHjWJtaqyGxObge59UH9Dh7nSxLu9KIC8gat0YxB0O80bEu5NAh91Z
> dJDoFVYB53JTJ+8+eXqEumRKHVM9TOiNSLRkKH/IhwKxT6Z9ZUonHBN8zAVhs7jC
> WlP+7enJ+7emLdih93icY6lSLWpg91pQXRzqYOdnzMdMYkgMiZbrQmSDLGfe2KCC
> 6fzwslJBgPpoBcjs4FdpvBqF5JUguDGBoN5LJq5G800WhYCqsYQ+yaTlbIxlpqUM
> KorZxmKkQacQy45CN/Kr4jNv/8YPgSDTIbXG9W9uDQjqWLyCrXCAaTxKnEKJrwN8
> jfoEslYlnLivYPkhPSJJvQ8HCutb37I4Md+8u7TmOnL1XeQRHoC+cRybe4C6mBAP
> cec+5vFoGZkYMEO6Cxc6jfGAPx7+3iSY5ZtzFUkloOk3VZVQPbf6ytPRbdFO6PY0
> xweeyU3E8LPHf3fSU4IdEPZ8Unp6fXzMFupXOIHHzw6bTiP0+q1TXASDvPmvdDwp
> fcYLYvKNXOTFXKJGV1zr5bln4x8rg8P8H8LgLunhSvYm0LPkJ58A9+Sepk7sFjdf
> 2iF5CC3yaZ6SBLen+aS3CHEcPS1ZrUH9rfNsp4ej4qXkP/Zxf9cUQJmQgfd2oU7b
> EjTPOfJpR1x9P0nPMTnr
> =tmf/
> -----END PGP SIGNATURE-----
>
--
You received this message because you are subscribed to the Google Groups
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.
