Perhaps you could see what mongrel2 (http://mongrel2.org) is doing? I think they've already got a pretty robust webserver that using asynchronous io without too much code in the way.
On Wed, Oct 13, 2010 at 10:44 AM, john skaller <skal...@users.sourceforge.net> wrote: > > On 12/10/2010, at 3:07 PM, john skaller wrote: > >> >> Ok, the Felix webserver (in tools directory) is not behaving itself. >> There seems to be an attempt to write on a closed connection, >> after which the server just exits for unknown reason. > > > Well now I know: > > Add socket wakeup > Added write filter > close read fd 17file /Users/johnskaller/Desktop/Python-Docs-2.5.2/tut/tut.html > Add socket wakeup > Added read filter > Kqueue got 1 events > EVFILT_WRITE: can write (?) 146988 bytes > got EV_EOF on write, socket = 16, data bytes =146988 (0?), errno/fflags?=0 > posix faio wakeup PDEMUX_WRITE, writing.. > posix_demuxer:socket_send > posix_demuxer:socket_send wrote -1 bytes > posix_demuxer: socket send failed, connection closed by client? > send: Broken pipe > Should have printed the error code above .. > posix faio wakeup PDEMUX_WRITE, connection closed = 1 > faio_req=0x100504a80, Notify 0x1005037c0 > faio_req=0x100504a80, FINISHED > ETHREAD CHECKING QUIT FLAG > ETHREAD ABOUT TO WAIT > Kqueue got 1 events > EVFILT_READ: got 132 bytes coming > posix faio wakeup PDEMUX_READ, reading.. > posix_demuxer:socket_recv > posix_demuxer:socket_recv got 132 bytes > posix faio wakeup PDEMUX_READ, connection closed = 0 > Add socket wakeup > Added read filter > ETHREAD CHECKING QUIT FLAG > ETHREAD ABOUT TO WAIT > > Program received signal SIGPIPE, Broken pipe. > 0x00007fff835ba316 in __semwait_signal () > (gdb) > > So basically, an attempt to write on a broken connection leading > to SIGPIPE killing the program .. grrr ... :) > > I'm not sure how to fix this, in fact I'm not sure it is POSSIBLE to > fix it ;( [Other than by disabling that stupid signal :] > > The problem is that the connection can be closed at any > time during an async write operation, or between the > notification there's space to write and the actual write > proceeding. > > <flame> > IN FACT it can occur AFTER the client write is done, but > before the OS has transmitted the data .. which is in fact > exactly what happens when you close an asynchronous > socket (all the data which is CERTAINLY just put > in the buffer is lost due to a bug in POSIX). > </flame> > > Actually I do not know WHY the connection is closed! > It happens using both Firefox (loading a page with > images, which are loaded in parallel), and also using > two concurrent instances of curl.. what ever firefox does, > curl will be doing something sane. > > The design of sockets (and perhaps the underlying TCP/IP > protocol?) is poorly designed. IMHO ;) > > What the webserver does is read the GET line and then > shutdown its read half of the socket. It is NOT ACCEPTABLE > to read the whole message, since this opens up the webserver > to a DNS attack. However it doesn't have to shutdown its reader > (the client's sender). > > Then it sends to the client. In a robust server, this has to be time limited, > again to prevent a DNS attack. > > Now it could be the shutdown, possibly before the whole message is read, > is fooling the client into believing its request isn't going to be serviced, > leading the client to shutdown *its* reader, which means the connection > is then dead. > > It's also possible this doesn't happen on a single file request because > the "random" ordering of the shutdown? Not sure, but a sequence of > single requests always seems to succeed.. sometimes multiple requests > also appear to succeed. > > Hmmm .. > > > -- > john skaller > skal...@users.sourceforge.net > > > > > -- > You received this message because you are subscribed to the Google Groups > "Felix Language" group. > To post to this group, send email to felix-langu...@googlegroups.com. > To unsubscribe from this group, send email to > felix-language+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/felix-language?hl=en. > > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
