On Fri, Mar 01, 2013 at 08:56:04PM -0500, Andrew Sillers wrote:
> Also, I just realized that Websockify can server Web content with the --web DIR
>  option. This means that (if we want), a Vanilla Netrek server could act as Web
> host to serve the HTML5 client and as a Websocket server to directly handle
> Websocket traffic from the client.

We tend to use Apache at the moment for that.  The server generates an
event blog and player scores to configured HTML directories.

> Incidentally, if you look at http://netrek.nodester.org, I've added the
> beginnings of a tutorial. I've included basic moving and shooting controls, but
> I've run into the problem that any advanced instruction requires other people
> on the server: specifically, getting kills to enable carrying. I suppose the
> existing bots could work for this, but it seems regrettable that I must ask a
> newbie to score a kill before he can learn about how winning the game actually
> works.
> I've also added Xbox 360 gamepad support for Chrome in the Github repo (it's
> really neat!), but I haven't pushed it to Nodester yet because their service is
> on the fritz at the moment.
> Andrew
> On Fri, Mar 1, 2013 at 8:40 PM, Andrew Sillers <apsillers at gmail.com> wrote:
>     My proxy is a simple Websocket-to-TCP proxy, which can easily be run on the
>     same machine as the actual server. The proxy code is largely a reinvention
>     of Websockify (https://github.com/kanaka/websockify), which I didn't know
>     about when I started coding this a year ago. Websockify actually would be
>     perfect for this task. If you look in their Github README, you'll see:
>     > websockify has the ability to launch a program on the local system and
>     proxy WebSockets traffic to a normal TCP port owned/bound by the program
>     which means that you could run `./websockify 16446 localhost:2592` on your
>     server, and now any incoming Websocket traffic will be routed as plain TCP
>     to port 2592.
>     I really *should* be using Websockify, because their error-handling support
>     is much more robust, and it would remove a dependency on Node.js.
>     (Websockify is plain C, which makes it perfect for packaging alongside the
>     rest of the server code.) I'll need to rewrite a few things to make the
>     code play nice with Websockify, but I think I'll do that shortly and get
>     rid of the need for my custom proxy altogether.
>     Andrew
>     On Fri, Mar 1, 2013 at 5:17 PM, James Cameron <quozl at us.netrek.org> wrote:
>         On Fri, Mar 01, 2013 at 02:49:05PM +0100, Sven Neuhaus wrote:
>         > Hi Andrew et al,
>         >
>         > this project is highly interesting. With the advent of WebRTC and
>         > RTCDatachannel browsers can now use UDP peer2peer communication,
>         which
>         > will be a great boost for lag sensitive games such as netrek.
>         >
>         > It would be even better if we had an alternative protocol for netrek
>         > (that the server also understands) so that no proxy is necessary for
>         web
>         > clients.
>         Agreed.  While UDP was once needed to optimise networks with loss and
>         reordering problems, modern networks are much better.  So a new
>         protocol with better compatibility for the web client sandbox
>         environment would be helpful.  The payload need not change, but the
>         transport can.
>         Alternatively, the proxy can be integrated into the server program set.
>         --
>         James Cameron
>         http://quozl.linux.org.au/
>         _______________________________________________
>         netrek-dev mailing list
>         netrek-dev at us.netrek.org
>         http://mailman.us.netrek.org/mailman/listinfo/netrek-dev

James Cameron