Hi Justin, You have 2 options I guess; one is to just "fake it" by issuing Register_read()/Register_write() commands on each keep-alive to make the kill code think there is activity. That's a bit hacky but could be done right now without changing any mongrel2 code.
The other option would be to change the code in src/register.c to do something meaningful with keep-alives. Right now, I just disable all idle-killing code if I'm using websockets; it does leave us potentially open to slowlorris type attacks, but we can bomb that bridge when we get to it. -Jason On 14:58 Fri 26 Apr , Justin Karneges wrote: > Excellent, that seems like it should be plenty extensible, although I'm > not sure about the interface being related to plugins. Does this mean > that the proper use for something like this would be to create a plugin > called "keep-alive" or such, and then pass that name as the first (and > probably only) value in the list? > > Would a plugin be able to control the timeout values of connections? Or > would I need to extend mongrel's plugin API to do that? (stupid > question, I haven't looked at the filters stuff at all yet) > > On 04/26/2013 02:38 PM, Jason Miller wrote: > > Way ahead of you Justin: > > https://github.com/zedshaw/mongrel2/commit/72602f91cfb85d3975a4366ab2dbfeb1a756b7c8 > > > > Quick summary; set the first connection id to "X" to indicate an > > extended request. > > > > The payload must then be a tnetstring list. The first item in the list > > is used as an identifier to dispatch to a plugin. The rest of the list > > will be specific to the type it is. > > > > I implemented an example "X-Sendfile" like interface as an example of > > how to use it. Links to them in github below. > > > > -Jason > > > > Python handler: > > https://github.com/zedshaw/mongrel2/blob/develop/examples/http_0mq/sendfile.py > > > > Plugin to go with it: > > https://github.com/zedshaw/mongrel2/blob/develop/tools/filters/sendfile.c > > > > On 08:46 Fri 26 Apr , Justin Karneges wrote: > >> Hey people, > >> > >> I want to be able to do more with responses but I'm not sure how to > >> extend the format without breaking backwards compatibility. > >> > >> Maybe a good way to handle this is to have mongrel2 inform its ability > >> to support additional formatting in the messages that it sends to > >> workers. Then workers can respond with a non-backwards-compatible > >> format, but this is okay, since they'd have confirmed that the version > >> of mongrel2 talking to them is capable of understanding it. > >> > >> Maybe we could use another all-uppercase header to trigger this, like > >> "EXTENDED_RESPONSE" set to "1". Responses could be of the form: > >> "{instance} {tnet request id(s) string} {tnet extension dict} {data}". > >> Then we can forever play with that extension dict and hopefully not have > >> to hack anything on top of the system again. > >> > >> One type of extension I want to add is the ability to keep-alive a > >> connection (reset mongrel2's internal timer for the connection) without > >> having to actually send data down to the client. Currently, sending 0 > >> data means disconnect, so we need another way. We could use the > >> extension dict to set something like keep-alive=true. > >> > >> Really would like feedback on this before I start hacking. Thanks. :) > >> > >> Justin > >> > >
