Hi, First, thanks for the nifty project. :) I notice that mongrel2 times out connections after about 2 minutes of inactivity. I'd like to be able to keep the connection open indefinitely, even if I have nothing to send. Is this possible? I'm considering sending periodic responses of 0 length if that might instruct mongrel2 to retain the connection without relaying anything to the client. I also want to be able to know if the client disconnects an otherwise silent connection, so maybe this can be used as a way to induce the disconnect message from mongrel2 even if I have no real data to send? Thanks, Justin
Hello, > First, thanks for the nifty project. :) > > I notice that mongrel2 times out connections after about 2 minutes of > inactivity. I'd like to be able to keep the connection open indefinitely, even > if I have nothing to send. Is this possible? Yes, check the manualy, you have 3 settings to set to control the timeout. http://mongrel2.org/static/book-finalch4.html#x6-410003.10 limits.min_ping limits.min_write_rate limits.min_read_rate > I'm considering sending periodic responses of 0 length if that might instruct > mongrel2 to retain the connection without relaying anything to the client. I > also want to be able to know if the client disconnects an otherwise silent > connection, so maybe this can be used as a way to induce the disconnect > message from mongrel2 even if I have no real data to send? Send something, you will get an answer from Mongrel2 that the client was not here. (see json disconnect message) loïc
> > I'm considering sending periodic responses of 0 length if that might > > instruct mongrel2 to retain the connection without relaying anything to > > the client. I also want to be able to know if the client disconnects an > > otherwise silent connection, so maybe this can be used as a way to > > induce the disconnect message from mongrel2 even if I have no real data > > to send? > > Send something, you will get an answer from Mongrel2 that the client was > not here. (see json disconnect message) It seems if I send an empty reply, then mongrel2 interprets this to mean to disconnect the client. I need a way of checking client disconnect, without causing data to be sent to the client and without disconnecting the client. Is this possible? Justin
On 2012-02-04 22:16, Justin Karneges wrote: >>> I'm considering sending periodic responses of 0 length if that might >>> instruct mongrel2 to retain the connection without relaying anything to >>> the client. I also want to be able to know if the client disconnects an >>> otherwise silent connection, so maybe this can be used as a way to >>> induce the disconnect message from mongrel2 even if I have no real data >>> to send? >> >> Send something, you will get an answer from Mongrel2 that the client was >> not here. (see json disconnect message) > > It seems if I send an empty reply, then mongrel2 interprets this to mean to > disconnect the client. > > I need a way of checking client disconnect, without causing data to be sent to > the client and without disconnecting the client. Is this possible? Yes, it is called the "control port". http://mongrel2.org/static/book-finalch4.html#x6-390003.8 I think we need to let you read the manual top to bottom, it takes a bit of time but you will learn a lot. Have a nice day, loïc
On Saturday, February 04, 2012 08:31:07 PM Loic d'Anterroches wrote: > On 2012-02-04 22:16, Justin Karneges wrote: > > I need a way of checking client disconnect, without causing data to be > > sent to the client and without disconnecting the client. Is this > > possible? > > Yes, it is called the "control port". > http://mongrel2.org/static/book-finalch4.html#x6-390003.8 Hmm, status what=net returns the entire connection list. Is this a safe operation to run when the server has huge numbers of connections? Justin
On Sat, Feb 04, 2012 at 09:02:07PM -0800, Justin Karneges wrote: > > Yes, it is called the "control port". > > http://mongrel2.org/static/book-finalch4.html#x6-390003.8 > > Hmm, status what=net returns the entire connection list. Is this a safe > operation to run when the server has huge numbers of connections? It should be, but depends on what is "huge". The response is done as a tnetstring so it's efficient, and it will get transmitted pretty quick, but if we're talking millions then no probably not. However, you are sort of asking Mongrel2 to do something that the base IP protocol can't really do. If the client closes the connection there's situations where you might not find out for a while that they're gone, especially on a crappy network. Your best thing to do is enable a heartbeat to your protocol, and write the client so that they reconnect when things fail and use a more async id style. For example, instead of the client keeping things open forever, have them get an id for work they need and check a mailbox. For a heartbeat I'd exploit the websocket and flash socket stuff. You can use that for fairly low latency pings to the client. -- Zed A. Shaw http://zedshaw.com/
On Tuesday, February 07, 2012 07:15:40 PM Zed A. Shaw wrote: > On Sat, Feb 04, 2012 at 09:02:07PM -0800, Justin Karneges wrote: > > > Yes, it is called the "control port". > > > http://mongrel2.org/static/book-finalch4.html#x6-390003.8 > > > > Hmm, status what=net returns the entire connection list. Is this a safe > > operation to run when the server has huge numbers of connections? > > It should be, but depends on what is "huge". The response is done as a > tnetstring so it's efficient, and it will get transmitted pretty quick, > but if we're talking millions then no probably not. > > However, you are sort of asking Mongrel2 to do something that the base > IP protocol can't really do. If the client closes the connection > there's situations where you might not find out for a while that they're > gone, especially on a crappy network. I don't mind if it takes awhile for me to recognize a missing connection. I just need to know eventually, so I can free associated resources. Heartbeats would allow inducing the error sooner, yes, but I want my application to be able to work without heartbeats in certain contexts (with the understanding that, if used this way, it may take a long time to recognize a disconnect). If a single mongrel2 instance has a million connections (is this even possible? :)), then I don't mind if it takes me a long time (minutes) to download the list. What I'm more concerned about is congesting mongrel2 during the retrieval. I would not want the act of retrieving this list to cause blockage of HTTP service or anything like that. Justin