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: http://apsillers.github.com/html5-netrek/ 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 netrek.apsillers.com (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.) 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. The new proxy-free code is in the ws-direct branch: https://github.com/apsillers/html5-netrek/tree/ws-direct Andrew On Mon, Mar 4, 2013 at 6:38 PM, Andrew Sillers <apsillers at gmail.com> wrote: > > 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 > > The JavaScript code to create binary Netrek protocol messages is already > in place at > https://github.com/apsillers/html5-netrek/blob/master/js/packets.js. 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. > > > > However, we want to take advantage of WebRTC's capability to use UDP! > > ...we could hopefully reuse most of the normal netrek UDP protocol > (inside WebRTC) once the packets are flowing. > > 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. > > 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 ( > https://github.com/apsillers/html5-netrek/tree/phonegap; 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. > > 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. > > Andrew > > > > Now, on the client side 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 (even at the > > cost of higher bandwidth usage). > > On Mon, Mar 4, 2013 at 6:12 AM, James Cameron <quozl at us.netrek.org> wrote: > >> On Mon, Mar 04, 2013 at 11:31:33AM +0100, Sven Neuhaus wrote: >> > Am 02.03.2013 02:40, schrieb Andrew Sillers: >> > > My proxy is a simple Websocket-to-TCP proxy, which can easily be run >> on >> > > the same machine as the actual server. >> > >> > Nice. However, we want to take advantage of WebRTC's capability to use >> > UDP! I think proxy-wise all we need to support WebRTC would be something >> > to initiate the UDP peer2peer connection [in this case between the >> > browser and the netrek server acting as WebRTC endpoint], we could >> > hopefully reuse most of the normal netrek UDP protocol (inside WebRTC) >> > once the packets are flowing. >> > >> > Now, on the client side 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 (even at the >> > cost of higher bandwidth usage). >> >> Yes, the original binary Netrek protocol is somewhat difficult to deal >> with using today's application languages, and has a few hidden >> behaviours that are surprising. >> >> JSON is used by the Gytha Netrek client for maintaining the >> achievements data on the user's filesystem. I picked it for minimum >> coding time. >> >> In the context of the network protocol though, JSON is a reasonable >> tradeoff between compressibility, coding time, and performance. It is >> a well known format. >> >> But I can't stop thinking of JSON as just another instance of Lisp >> s-expressions! ;-) >> >> A server side protocol translator would not be difficult. I don't see >> any great need to tightly integrate it into the shared memory system >> used by ntserv and daemon. >> >> -- >> 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/20130304/0a218e7a/attachment-0001.html>