> 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>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.<br>
<br>> However, we want to take advantage of WebRTC's capability to use UDP!<br>> ...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.<br>
<br>Andrew<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 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>