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

Reply via email to