Also, I just realized that Websockify can server Web content with the --web
DIR option. This means that (if we want), a Vanilla Netrek server could act
as Web host to serve the HTML5 client and as a Websocket server to directly
handle Websocket traffic from the client.

Incidentally, if you look at http://netrek.nodester.org, I've added the
beginnings of a tutorial. I've included basic moving and shooting controls,
but I've run into the problem that any advanced instruction requires other
people on the server: specifically, getting kills to enable carrying. I
suppose the existing bots could work for this, but it seems regrettable
that I must ask a newbie to score a kill before he can learn about how
winning the game actually works.

I've also added Xbox 360 gamepad support for Chrome in the Github repo
(it's really neat!), but I haven't pushed it to Nodester yet because their
service is on the fritz at the moment.

Andrew


On Fri, Mar 1, 2013 at 8:40 PM, Andrew Sillers <apsillers at gmail.com> wrote:

> 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/9de3688c/attachment-0001.html>