OK, thanks. I think I am slowly starting to understand how this works now. Standard HTTP servers like Lighttpd can be configured to act as (reverse) proxy for other servers, using dedicated modules designed for that task. This then maps what otherwise would have been a filename in the server tree onto an IP address + port and protocol. This way hgm.nubati.net/ics could configured to become a Websocket access point, so it could be used as ws://hgm.nubati.net/ics, which would forward the connection to port 5000 on the same machine after decoding the Websocket protocol to normal TCP/IP. (That is, the client would communicate to the proxy in Websocket protocol, which is a layer on top of TCP/IP, and the proxy would strip or add the Websocket headers, and relay the data over a TCP connection to the ICS.)
I suspect many of the hits I got when trying to figure this out were actually dealt with how to make a Websocket module for a HTTP server, which was rather confusing.
So Websockets seem indeed designed for applications like broadcasting, allowing JavaScript clients to open a permanent communication link to the server they came from. If I would be designing something from scratch, it would be the obvious choice.
It would render what I already have (a CGI server script handling game polling requests, which also handles submission of moves after user identification, requests for user registration, and creation of new games between registered users, as on
http://hgm.nubati.net/variants/werewolf ) totally useless. Deferring the polling response for future moves on games where the players are currently connected, so that the move can be pushed to the client without delay once it arrives, would only be a minor modification to that existing system. (If it works, and if it does not overload the server.)
To support real-time games, I guess I would also have to improve the method for challenging opponents. In the turn-based server you could just start a game against any registered player, with the idea that he would sooner or later drop by and do a move. (Or not, and then the server could delete games that had only 0 or 1 moves after a month.) You wouldn't want to start a real-time game against an opponent that is not currently connected, though. And I might want to allow negociation over the time control before the game starts. The basic system could allow that by letting the client always have one long-polling request, which puts itself in a file on the server with an indication what the client is waiting for (a move of a specified game as an observer or as the white or black player, a challenge for a game, or just a chat).
As such polling requests would have to be constantly renewed after they have been used to push some data (like a chat message) to the client, which could take some time, a request would have to linger in the list of pending requests until it has time to be renewed. This could be achieved by replacing the process ID in the list of pending requests by a time-stamp indicating when the request was satisfied, considering such a slot empty (and available to log new requests) only 10 sec (say) after the time stamping. The CGI script could then always know which clients are currently connected, and what events they are waiting for, so that when that event (submission of a move or acceptance of a challenge for a game) occurs, the poll requests waiting for it can be triggered to complete by a signal.
