Update: I have made a proxy-free branch that assumes the Netrek server is listening for WebSocket connections on port 16446 and connects directly. See the demo here: <a href="http://apsillers.github.com/html5-netrek/">http://apsillers.github.com/html5-netrek/</a><br>
<br>This is nice because it removes my dependency on Node.js hosting and instead foists the WS-toTCP proxying onto the Netrek server itself, thereby eliminating the need for a middle server. The JS code is statically hosted on Github, and my personal server on <a href="http://netrek.apsillers.com">netrek.apsillers.com</a> (which I set up yesterday) is listening on both 2592:tcp as well as 16446:ws by way of Websockify, used simply with `python websockify.py -D 16445 localhost:2592`. (Note that in a previous message I suggested using C-based Websockify, but it appears that it hasn't been updated to comply with the latest WS standard, whereas the Python version has.)<br>
<br>The downside is that the proxy-less version can only connect to servers that run Websockify (or similar) to listen on a WebSocket port. It might be possible to build a hybrid system that assumes server-hosted WS-to-TCP translation but uses a proxy as a fallback.<br>
<br>The new proxy-free code is in the ws-direct branch: <a href="https://github.com/apsillers/html5-netrek/tree/ws-direct">https://github.com/apsillers/html5-netrek/tree/ws-direct</a><br><br>Andrew<br><br><div class="gmail_quote">
On Mon, Mar 4, 2013 at 6:38 PM, Andrew Sillers <span dir="ltr"><<a href="mailto:apsillers@gmail.com" target="_blank">apsillers@gmail.com</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">> with JavaScript, the original binary Netrek protocol is probably a pain to deal with(?), so perhaps using something simple yet compact (JSON comes to mind) would be better<br><br></div>The JavaScript code to create binary Netrek protocol messages is already in place at <a href="https://github.com/apsillers/html5-netrek/blob/master/js/packets.js" target="_blank">https://github.com/apsillers/html5-netrek/blob/master/js/packets.js</a>. I'll admit it was a bit of a pain to set up, but it's virtually complete now, so implementing a JSON-to-binary converter wouldn't afford a large benefit to this particular project. However, it might ease the setup cost for new developers and new clients (i.e., they could skip the "bit of a pain to set up" step), so there's certainly some merit to the idea.<div class="im">
<br>
<br>> However, we want to take advantage of WebRTC's capability to use UDP!<br></div>> ...we could hopefully reuse most of the normal netrek UDP protocol (inside WebRTC) once the packets are flowing.<br><br>Agreed. The NetrekConnection class (inside net.js) basically does this with a Websocket-wrapped TCP setup, so I expect it's possible to implement a WebRTC-wrapped UDP setup.<br>
<br>I feel I should also point out that the Netrek JavaScript and HTML code is usable outside of a traditional Web browser. I've toyed with a Chrome web app deployment using Chrome's socket APIs, which include both TCP and UDP support. I've also made an Android application (<a href="https://github.com/apsillers/html5-netrek/tree/phonegap" target="_blank">https://github.com/apsillers/html5-netrek/tree/phonegap</a>; actual .apk executable in /bin) using Phonegap and a simple TCP plugin that I wrote. I could easily implement a UDP plugin for Phonegap and (less easily) integrate it into the JavaScript networking code. The NetrekConnection class in my JS code simply exposes an abstract API for sending and receiving data that rest of the code uses; the only that needs to change between platforms is the raw networking code that implements that API. WebRTC is definitely the way to go for a lossy data channel in the Web browser, but other Javascript-based platforms can expose direct TCP and UDP APIs that don't require a proxy or interpreter at all.<br>
<br>That last paragraph is neither here nor there with respect to the current topic (which is focused on Web browser support), but I thought I'd share it just to give a more comprehensive view of future options for this code.<span class="HOEnZb"><font color="#888888"><br>
<br>Andrew</font></span><div class="im HOEnZb"><br><br><br>Now, on the client side with JavaScript, the original binary Netrek<br>
> protocol is probably a pain to deal with(?), so perhaps using something<br>
> simple yet compact (JSON comes to mind) would be better (even at the<br>
> cost of higher bandwidth usage).<br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_quote">On Mon, Mar 4, 2013 at 6:12 AM, 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>On Mon, Mar 04, 2013 at 11:31:33AM +0100, Sven Neuhaus wrote:<br>
> Am 02.03.2013 02:40, schrieb Andrew Sillers:<br>
> > My proxy is a simple Websocket-to-TCP proxy, which can easily be run on<br>
> > the same machine as the actual server.<br>
><br>
> Nice. However, we want to take advantage of WebRTC's capability to use<br>
> UDP! I think proxy-wise all we need to support WebRTC would be something<br>
> to initiate the UDP peer2peer connection [in this case between the<br>
> browser and the netrek server acting as WebRTC endpoint], we could<br>
> hopefully reuse most of the normal netrek UDP protocol (inside WebRTC)<br>
> once the packets are flowing.<br>
><br>
> Now, on the client side with JavaScript, the original binary Netrek<br>
> protocol is probably a pain to deal with(?), so perhaps using something<br>
> simple yet compact (JSON comes to mind) would be better (even at the<br>
> cost of higher bandwidth usage).<br>
<br>
</div>Yes, the original binary Netrek protocol is somewhat difficult to deal<br>
with using today's application languages, and has a few hidden<br>
behaviours that are surprising.<br>
<br>
JSON is used by the Gytha Netrek client for maintaining the<br>
achievements data on the user's filesystem. I picked it for minimum<br>
coding time.<br>
<br>
In the context of the network protocol though, JSON is a reasonable<br>
tradeoff between compressibility, coding time, and performance. It is<br>
a well known format.<br>
<br>
But I can't stop thinking of JSON as just another instance of Lisp<br>
s-expressions! ;-)<br>
<br>
A server side protocol translator would not be difficult. I don't see<br>
any great need to tightly integrate it into the shared memory system<br>
used by ntserv and daemon.<br>
<div><br>
--<br>
James Cameron<br>
<a href="http://quozl.linux.org.au/" target="_blank">http://quozl.linux.org.au/</a><br>
</div><div><div>_______________________________________________<br>
netrek-dev mailing list<br>
<a href="mailto:netrek-dev@us.netrek.org" target="_blank">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></div></blockquote></div><br>