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 (<a href="https://github.com/kanaka/websockify">https://github.com/kanaka/websockify</a>), 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:<div>
<br></div><div>> <span style="color:rgb(51,51,51);font-family:Helvetica,arial,freesans,clean,sans-serif;font-size:14px;line-height:22px;background-color:rgb(255,255,255)">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</span><br>
<br>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.</div><div><br></div><div>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.</div>
<div><br></div><div>Andrew</div><div><br><br><div class="gmail_quote">On Fri, Mar 1, 2013 at 5:17 PM, James Cameron <span dir="ltr"><<a href="mailto:quozl@us.netrek.org" target="_blank">quozl@us.netrek.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Mar 01, 2013 at 02:49:05PM +0100, Sven Neuhaus wrote:<br>
> Hi Andrew et al,<br>
><br>
> this project is highly interesting. With the advent of WebRTC and<br>
> RTCDatachannel browsers can now use UDP peer2peer communication, which<br>
> will be a great boost for lag sensitive games such as netrek.<br>
><br>
> It would be even better if we had an alternative protocol for netrek<br>
> (that the server also understands) so that no proxy is necessary for web<br>
> clients.<br>
<br>
</div>Agreed.  While UDP was once needed to optimise networks with loss and<br>
reordering problems, modern networks are much better.  So a new<br>
protocol with better compatibility for the web client sandbox<br>
environment would be helpful.  The payload need not change, but the<br>
transport can.<br>
<br>
Alternatively, the proxy can be integrated into the server program set.<br>
<div class="im HOEnZb"><br>
--<br>
James Cameron<br>
<a href="http://quozl.linux.org.au/" target="_blank">http://quozl.linux.org.au/</a><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
netrek-dev mailing list<br>
<a href="mailto:netrek-dev@us.netrek.org">netrek-dev@us.netrek.org</a><br>
<a href="http://mailman.us.netrek.org/mailman/listinfo/netrek-dev" target="_blank">http://mailman.us.netrek.org/mailman/listinfo/netrek-dev</a><br>
</div></div></blockquote></div><br></div>