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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20130301/4e6d6fd8/attachment.html>