From sven-netrek-dev at sven.de  Fri Mar  1 07:49:05 2013
From: sven-netrek-dev at sven.de (Sven Neuhaus)
Date: Fri, 01 Mar 2013 14:49:05 +0100
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
Message-ID: <5130B1D1.8000601@sven.de>

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.

-Sven


From quozl at us.netrek.org  Fri Mar  1 16:17:22 2013
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 2 Mar 2013 09:17:22 +1100
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <5130B1D1.8000601@sven.de>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de>
Message-ID: <20130301221722.GA6053@us.netrek.org>

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/

From basic at us.netrek.org  Fri Mar  1 16:23:02 2013
From: basic at us.netrek.org (Bob Tanner)
Date: Fri, 1 Mar 2013 16:23:02 -0600
Subject: [netrek-dev] Mock Server?
References: <kdkani$gq8$1@ger.gmane.org>
Message-ID: <kgr9o3$l4r$1@ger.gmane.org>

On 2013-01-21 21:07:56 +0000, Bob Tanner said:

> Is there a way to simulate (mock object) the server?

Like most of the mock objects I've written my test suite passes with 
flying colors!

BUT

When I point it at a live server I missed a whole bunch of things.

Does gytha allow you to capture the packet stream and just write to the 
disk as binary data?

I want live server stream saved as a file so I can play it over and 
over again as part of the test suite.

-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = 9906 320A 8BB6 64AD 96A7  7785 CBFB 10BF 568B F98C



From quozl at us.netrek.org  Fri Mar  1 16:56:03 2013
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 2 Mar 2013 09:56:03 +1100
Subject: [netrek-dev] Mock Server?
In-Reply-To: <kgr9o3$l4r$1@ger.gmane.org>
References: <kdkani$gq8$1@ger.gmane.org>
 <kgr9o3$l4r$1@ger.gmane.org>
Message-ID: <20130301225603.GC6053@us.netrek.org>

On Fri, Mar 01, 2013 at 04:23:02PM -0600, Bob Tanner wrote:
> Does gytha allow you to capture the packet stream and just write to
> the disk as binary data?

Not as written, but it would not be difficult.

Look at gytha/client.py and locate each of the three calls to
instance.handler, and make them call something that writes to disk.

Opportunity exists to also write a timing record, for which I suggest
a time since connection or file open.

I think the general problem was solved by COW or cambot recording
years ago, but paging in that code to our respective brains may take
longer.

-- 
James Cameron
http://quozl.linux.org.au/

From apsillers at gmail.com  Fri Mar  1 19:40:52 2013
From: apsillers at gmail.com (Andrew Sillers)
Date: Fri, 1 Mar 2013 20:40:52 -0500
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <20130301221722.GA6053@us.netrek.org>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
Message-ID: <CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>

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/4e6d6fd8/attachment.html>

From apsillers at gmail.com  Fri Mar  1 19:56:04 2013
From: apsillers at gmail.com (Andrew Sillers)
Date: Fri, 1 Mar 2013 20:56:04 -0500
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
Message-ID: <CAAHY0jSjXkO9cnB7vv=TqEhKX=RMycy87kFcRiats6DYaHx1tg@mail.gmail.com>

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>

From quozl at us.netrek.org  Fri Mar  1 20:34:08 2013
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 2 Mar 2013 13:34:08 +1100
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <CAAHY0jSjXkO9cnB7vv=TqEhKX=RMycy87kFcRiats6DYaHx1tg@mail.gmail.com>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
	<CAAHY0jSjXkO9cnB7vv=TqEhKX=RMycy87kFcRiats6DYaHx1tg@mail.gmail.com>
Message-ID: <20130302023408.GE6053@us.netrek.org>

On Fri, Mar 01, 2013 at 08:56:04PM -0500, Andrew Sillers wrote:
> 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.

We tend to use Apache at the moment for that.  The server generates an
event blog and player scores to configured HTML directories.

> 
> 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
> 
> 
> 
> 

-- 
James Cameron
http://quozl.linux.org.au/

From karthik at karthik.com  Fri Mar  1 23:51:31 2013
From: karthik at karthik.com (Karthik Arumugham)
Date: Sat, 2 Mar 2013 00:51:31 -0500
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <20130301221722.GA6053@us.netrek.org>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
Message-ID: <7B813CD0-957B-4E7F-B4FC-FB32A041C827@karthik.com>

On 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.

Modern networks may be significantly better, but there's still far too much loss and jitter on the average consumer connection to NOT use UDP for a latency-sensitive game like Netrek. Of course, TCP is and can still be an option if UDP is not available.

Even across a single network, or even a single link, it's hard to get anyone to care unless packet loss is > 0.1% or so, if even that. Those small occasional losses build up, along with last-mile congestion on consumer connections. Netrek starts to suffer at perhaps 0.2 - 0.5% loss if you're using using TCP and depending on retransmits. (Obviously, that's latency-dependent as well, and depends on the structure of the loss.)

The newer frameworks that Sven refers to again just use UDP? So, basically, UDP isn't going anywhere if Netrek is going to be playable for anyone with loss. Unless someone feels like implementing SCTP. :)


From quozl at us.netrek.org  Sat Mar  2 01:09:28 2013
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 2 Mar 2013 18:09:28 +1100
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <7B813CD0-957B-4E7F-B4FC-FB32A041C827@karthik.com>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<7B813CD0-957B-4E7F-B4FC-FB32A041C827@karthik.com>
Message-ID: <20130302070928.GG6053@us.netrek.org>

On Sat, Mar 02, 2013 at 12:51:31AM -0500, Karthik Arumugham wrote:
> On 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.
> 
> Modern networks may be significantly better, but there's still far
> too much loss and jitter on the average consumer connection to NOT
> use UDP for a latency-sensitive game like Netrek. Of course, TCP is
> and can still be an option if UDP is not available.

Sure, real Netrek players will continue to use UDP and the original
protocol.  I'm not talking about them.  Anything I do on this would be
for increasing involvement by new players, and they have no
playability metric in their head.  I don't want the perfect to be the
enemy of the good.

> Even across a single network, or even a single link, it's hard to
> get anyone to care unless packet loss is > 0.1% or so, if even
> that. Those small occasional losses build up, along with last-mile
> congestion on consumer connections. Netrek starts to suffer at
> perhaps 0.2 - 0.5% loss if you're using using TCP and depending on
> retransmits. (Obviously, that's latency-dependent as well, and
> depends on the structure of the loss.)
> 
> The newer frameworks that Sven refers to again just use UDP? So,
> basically, UDP isn't going anywhere if Netrek is going to be
> playable for anyone with loss. Unless someone feels like
> implementing SCTP. :)

I didn't suggest removing UDP support.

I'll accept patches to add SCTP.

How about UDT?  Includes NAT traversal.

-- 
James Cameron
http://quozl.linux.org.au/

From sven-netrek-dev at sven.de  Mon Mar  4 04:31:33 2013
From: sven-netrek-dev at sven.de (Sven Neuhaus)
Date: Mon, 04 Mar 2013 11:31:33 +0100
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
Message-ID: <51347805.2020302@sven.de>

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).

Any takers? :-)
-Sven


From quozl at us.netrek.org  Mon Mar  4 05:12:16 2013
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 4 Mar 2013 22:12:16 +1100
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <51347805.2020302@sven.de>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
	<51347805.2020302@sven.de>
Message-ID: <20130304111216.GA6204@us.netrek.org>

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/

From apsillers at gmail.com  Mon Mar  4 17:38:49 2013
From: apsillers at gmail.com (Andrew Sillers)
Date: Mon, 4 Mar 2013 18:38:49 -0500
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <20130304111216.GA6204@us.netrek.org>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
	<51347805.2020302@sven.de> <20130304111216.GA6204@us.netrek.org>
Message-ID: <CAAHY0jRTZS9vy6UeCOY5Jt0RgVme7DYvMJs6C5JhZOnwdhmzRw@mail.gmail.com>

> 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/6af0c916/attachment.html>

From apsillers at gmail.com  Mon Mar  4 21:16:14 2013
From: apsillers at gmail.com (Andrew Sillers)
Date: Mon, 4 Mar 2013 22:16:14 -0500
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <CAAHY0jRTZS9vy6UeCOY5Jt0RgVme7DYvMJs6C5JhZOnwdhmzRw@mail.gmail.com>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
	<51347805.2020302@sven.de> <20130304111216.GA6204@us.netrek.org>
	<CAAHY0jRTZS9vy6UeCOY5Jt0RgVme7DYvMJs6C5JhZOnwdhmzRw@mail.gmail.com>
Message-ID: <CAAHY0jTXMq2dnUngkEOKjpHZ3QJ=-Bp1dM+z9W_n4hYuP=RhSg@mail.gmail.com>

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>

From sven-netrek-dev at sven.de  Sun Mar 10 05:58:24 2013
From: sven-netrek-dev at sven.de (Sven Neuhaus)
Date: Sun, 10 Mar 2013 11:58:24 +0100
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <CAAHY0jTXMq2dnUngkEOKjpHZ3QJ=-Bp1dM+z9W_n4hYuP=RhSg@mail.gmail.com>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
	<51347805.2020302@sven.de> <20130304111216.GA6204@us.netrek.org>
	<CAAHY0jRTZS9vy6UeCOY5Jt0RgVme7DYvMJs6C5JhZOnwdhmzRw@mail.gmail.com>
	<CAAHY0jTXMq2dnUngkEOKjpHZ3QJ=-Bp1dM+z9W_n4hYuP=RhSg@mail.gmail.com>
Message-ID: <513C6750.3030603@sven.de>

Great stuff Andrew!

Want bug reports? This is unrelated to the new websocket protocol stuff 
probably:
I noticed that the map border is not visible on the map and if you hit 
the northern border (I didn't try the other ones), the local map stops 
updating.

-Sven

From apsillers at gmail.com  Sat Mar 16 15:12:10 2013
From: apsillers at gmail.com (Andrew Sillers)
Date: Sat, 16 Mar 2013 16:12:10 -0400
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <513C6750.3030603@sven.de>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
	<51347805.2020302@sven.de> <20130304111216.GA6204@us.netrek.org>
	<CAAHY0jRTZS9vy6UeCOY5Jt0RgVme7DYvMJs6C5JhZOnwdhmzRw@mail.gmail.com>
	<CAAHY0jTXMq2dnUngkEOKjpHZ3QJ=-Bp1dM+z9W_n4hYuP=RhSg@mail.gmail.com>
	<513C6750.3030603@sven.de>
Message-ID: <CAAHY0jQPCFUwF5yX5Dgb1ew4yRHKzTvWM_N=vbD5LVE87wzU3A@mail.gmail.com>

> Want bug reports?

Thanks! I think the project the project is now mature enough to get bug
reports. I've been using the issue tracker on Github at
https://github.com/apsillers/html5-netrek/issues, which I think anyone can
write to. If you can't, let me know and I'll see what project settings I
need to change. I'd welcome bug reports, enhancement requests (especially
if it would make it more suitable for newbies), and comments on existing
reports (e.g., on "Improve Explosions" enhancement, a link to good 2D
explosion graphics).

Per your request, I've added in the map border, and I fixed the
update-failure bug.

I've also just added:
* Dynamic resizing so the game fills the whole screen
    * (this needs a little more work because the interface looks too sparse
when at a large size)
* Chat-to-all by default on chat bar click (like COW does)
* Fixed a major phaser bug
* Added steering and aiming pointers while playing with a gamepad

As always, my production code is running at http://netrek.nodester.org, my
proxy-free branch is running at http://apsillers.github.com/html5-netrek/,
and my code is at https://www.github.com/apsillers/html5-netrek.

Andrew




On Sun, Mar 10, 2013 at 6:58 AM, Sven Neuhaus <sven-netrek-dev at sven.de>wrote:

> Great stuff Andrew!
>
> Want bug reports? This is unrelated to the new websocket protocol stuff
> probably:
> I noticed that the map border is not visible on the map and if you hit the
> northern border (I didn't try the other ones), the local map stops updating.
>
> -Sven
>
> ______________________________**_________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/**mailman/listinfo/netrek-dev<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/20130316/9c448d67/attachment.html>

From netrek at gmail.com  Sat Mar 16 15:16:42 2013
From: netrek at gmail.com (Zachary Uram)
Date: Sat, 16 Mar 2013 16:16:42 -0400
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <CAAHY0jQPCFUwF5yX5Dgb1ew4yRHKzTvWM_N=vbD5LVE87wzU3A@mail.gmail.com>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
	<51347805.2020302@sven.de> <20130304111216.GA6204@us.netrek.org>
	<CAAHY0jRTZS9vy6UeCOY5Jt0RgVme7DYvMJs6C5JhZOnwdhmzRw@mail.gmail.com>
	<CAAHY0jTXMq2dnUngkEOKjpHZ3QJ=-Bp1dM+z9W_n4hYuP=RhSg@mail.gmail.com>
	<513C6750.3030603@sven.de>
	<CAAHY0jQPCFUwF5yX5Dgb1ew4yRHKzTvWM_N=vbD5LVE87wzU3A@mail.gmail.com>
Message-ID: <CAPu6UvACLKZbNxb+dUMF8Kyi0jT5++A1aVgOvvNajK499=qE6Q@mail.gmail.com>

http://netrek.nodester.org/ doesn't work

Server not found

          Firefox can't find the server at netrek.nodester.org.

Zach

On Sat, Mar 16, 2013 at 4:12 PM, Andrew Sillers <apsillers at gmail.com> wrote:
>> Want bug reports?
>
> Thanks! I think the project the project is now mature enough to get bug
> reports. I've been using the issue tracker on Github at
> https://github.com/apsillers/html5-netrek/issues, which I think anyone can
> write to. If you can't, let me know and I'll see what project settings I
> need to change. I'd welcome bug reports, enhancement requests (especially if
> it would make it more suitable for newbies), and comments on existing
> reports (e.g., on "Improve Explosions" enhancement, a link to good 2D
> explosion graphics).
>
> Per your request, I've added in the map border, and I fixed the
> update-failure bug.
>
> I've also just added:
> * Dynamic resizing so the game fills the whole screen
>     * (this needs a little more work because the interface looks too sparse
> when at a large size)
> * Chat-to-all by default on chat bar click (like COW does)
> * Fixed a major phaser bug
> * Added steering and aiming pointers while playing with a gamepad
>
> As always, my production code is running at http://netrek.nodester.org, my
> proxy-free branch is running at http://apsillers.github.com/html5-netrek/,
> and my code is at https://www.github.com/apsillers/html5-netrek.
>
> Andrew
>
>
>
>
>
> On Sun, Mar 10, 2013 at 6:58 AM, Sven Neuhaus <sven-netrek-dev at sven.de>
> wrote:
>>
>> Great stuff Andrew!
>>
>> Want bug reports? This is unrelated to the new websocket protocol stuff
>> probably:
>> I noticed that the map border is not visible on the map and if you hit the
>> northern border (I didn't try the other ones), the local map stops updating.
>>
>> -Sven
>>
>> _______________________________________________
>> netrek-dev mailing list
>> netrek-dev at us.netrek.org
>> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>
>
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>



-- 
http://www.fidei.org

From apsillers at gmail.com  Sat Mar 16 15:19:03 2013
From: apsillers at gmail.com (Andrew Sillers)
Date: Sat, 16 Mar 2013 16:19:03 -0400
Subject: [netrek-dev] HTML5 Netrek Lite
In-Reply-To: <CAPu6UvACLKZbNxb+dUMF8Kyi0jT5++A1aVgOvvNajK499=qE6Q@mail.gmail.com>
References: <CAAHY0jRy=6RxdUo4U6OS9L98KTKJQBSP7Z0NFR6b6ie35BFFiA@mail.gmail.com>
	<5130B1D1.8000601@sven.de> <20130301221722.GA6053@us.netrek.org>
	<CAAHY0jS7qTL6U5s6ujU0ny-eg7ovgONqCfco1mtw4ZFyOdOw3A@mail.gmail.com>
	<51347805.2020302@sven.de> <20130304111216.GA6204@us.netrek.org>
	<CAAHY0jRTZS9vy6UeCOY5Jt0RgVme7DYvMJs6C5JhZOnwdhmzRw@mail.gmail.com>
	<CAAHY0jTXMq2dnUngkEOKjpHZ3QJ=-Bp1dM+z9W_n4hYuP=RhSg@mail.gmail.com>
	<513C6750.3030603@sven.de>
	<CAAHY0jQPCFUwF5yX5Dgb1ew4yRHKzTvWM_N=vbD5LVE87wzU3A@mail.gmail.com>
	<CAPu6UvACLKZbNxb+dUMF8Kyi0jT5++A1aVgOvvNajK499=qE6Q@mail.gmail.com>
Message-ID: <CAAHY0jTSXpsv9Nh9_4fDypXt02tYt0Z2B=y8KroNGMSNATuUMw@mail.gmail.com>

Oops! http://netrek.nodester.com/

I meant .com, not .org!

On Sat, Mar 16, 2013 at 4:16 PM, Zachary Uram <netrek at gmail.com> wrote:

> http://netrek.nodester.org/ doesn't work
>
> Server not found
>
>           Firefox can't find the server at netrek.nodester.org.
>
> Zach
>
> On Sat, Mar 16, 2013 at 4:12 PM, Andrew Sillers <apsillers at gmail.com>
> wrote:
> >> Want bug reports?
> >
> > Thanks! I think the project the project is now mature enough to get bug
> > reports. I've been using the issue tracker on Github at
> > https://github.com/apsillers/html5-netrek/issues, which I think anyone
> can
> > write to. If you can't, let me know and I'll see what project settings I
> > need to change. I'd welcome bug reports, enhancement requests
> (especially if
> > it would make it more suitable for newbies), and comments on existing
> > reports (e.g., on "Improve Explosions" enhancement, a link to good 2D
> > explosion graphics).
> >
> > Per your request, I've added in the map border, and I fixed the
> > update-failure bug.
> >
> > I've also just added:
> > * Dynamic resizing so the game fills the whole screen
> >     * (this needs a little more work because the interface looks too
> sparse
> > when at a large size)
> > * Chat-to-all by default on chat bar click (like COW does)
> > * Fixed a major phaser bug
> > * Added steering and aiming pointers while playing with a gamepad
> >
> > As always, my production code is running at http://netrek.nodester.org,
> my
> > proxy-free branch is running at
> http://apsillers.github.com/html5-netrek/,
> > and my code is at https://www.github.com/apsillers/html5-netrek.
> >
> > Andrew
> >
> >
> >
> >
> >
> > On Sun, Mar 10, 2013 at 6:58 AM, Sven Neuhaus <sven-netrek-dev at sven.de>
> > wrote:
> >>
> >> Great stuff Andrew!
> >>
> >> Want bug reports? This is unrelated to the new websocket protocol stuff
> >> probably:
> >> I noticed that the map border is not visible on the map and if you hit
> the
> >> northern border (I didn't try the other ones), the local map stops
> updating.
> >>
> >> -Sven
> >>
> >> _______________________________________________
> >> netrek-dev mailing list
> >> netrek-dev at us.netrek.org
> >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> >
> >
> >
> > _______________________________________________
> > netrek-dev mailing list
> > netrek-dev at us.netrek.org
> > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> >
>
>
>
> --
> http://www.fidei.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20130316/b2d4ca73/attachment.html>