On Tue, May 17, 2016 at 2:17 AM, Super Twang <[email protected]> wrote: > > I've been using libuv to implement a custom http server to serve a web app. > The web app used bidirectional websocket protocols to move data back and > forth between the client and server. > > I'm a little confused as to how to handle the lifecycles for connected > clients. > > The 'after write' hook seems to give me the chance to delete clients, which > I could see doing upon receiving some kinds of errors, but with http clients > being, by design, able to drop out at any time, on either end, I don't > understand how I should differentiate between: > > * clients who've experienced a write error, but are still alive (the > error, for example, could be me trying to push data down the web socket > faster than the client can handle) These clients might benefit from some > throttling, but should be "tried again." > > * clients who are dead, and show up with a write error. These client > data structures should be deleted and forgotten. > > Is there a known metric within the libuv paradigm for when a client should > be considered "Gone forever," or is this entirely up to the use case? > > If you have architectural ideas on this, I'd really love to hear them. > > Thanks, > ST
If libuv reports an error, consider the connection dead. Your example of writing too fast doesn't really apply, libuv will start buffering data in that case. You can inspect handle->write_queue_size to stop the backlog from growing too large. -- 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 https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
