[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Handling HTTP "Upgrade" requests
From: |
Nala Ginrut |
Subject: |
Re: Handling HTTP "Upgrade" requests |
Date: |
Thu, 26 Feb 2015 15:51:40 +0800 |
On Wed, 2015-02-25 at 11:23 -0500, Dave Thompson wrote:
> IMO, an asynchronous/multi-threaded server is a separate issue. I was
> aiming for a solution that allowed a single websocket to be used on
> Guile's single-thread default web server. Of course, the websocket
> implementation should be able to be applied to a more advanced server,
> should one be written.
>
Ah I see.
> I think you're right that something in the default HTTP server must be
> changed, but I haven't grokked the implementation enough to figure it
> out. AFAICT, the HTTP server socket needs to be handed over to a
> WebSocket server procedure, suspending additional HTTP request
> processing until the WebSocket is closed and the socket is handed back
> to the HTTP server. Does that make some sense? Things are too foggy
> for me to tell.
Personally, I don't think websocket part should be based on inner HTTP
server. Or there'd be some changes of the architecture.
But if you really want to use inner server, I think there're some points
to be noticed:
1. check if it's websocket frame, then call the registered handler and
skip read-request to avoid the problem you've pasted;
2. the current inner server detects keep-alive based on HTTP header, so
you have to modify something to support comet connection for websocket
ports.
3. I have to mention that the current inner server is not non-block and
weak for slow-header-DDOS. So if you handle one request in a long time,
others' requests will be blocked in a long time. One of the easy
solution is to take advantage of Nginx reverse-proxy. But it doesn't
solve all the issues. ;-P
PS: To those who care, unfortunately, Guile has no epoll/kqueue yet,
that's one of the reasons why I want to write new server core for
Artanis. ;-)
Happy hacking!