gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Scripting Systems

[Jorrit T. <Jor...@uz...>]

Dan Thompson wrote:

>I've looked around and implemented a few systems, but I thought I'd get
>everyone's opinion on how scripting should be incorporated into a game. Note
>that I'm *not* talking about what language to use, or what the scripting
>should be used for, nessesarily. Also note that the archives search on
>sourceforge is the worst search engine ever known to mankind. If this has
>been covered already, I apologize.
>  
>

I'm the project manager of CEL (Crystal Entity Layer) which is a game 
entity layer
sitting on top of Crystal Space (see http://cel.sf.net for more info). 
In CEL we support
scripting in various languages (currently C++, Python, and XML are being 
used but other
languages are possible). The idea is that every entity gets a script 
associated with it
(which we call a 'behaviour' in CEL). Every entity also gets a number of 
property
classes which correspond to what that entity can do. For example, if you 
want to have
a 'chest' entity in an adventure game you could have an entity with the 
following
property classes:
    - pcmesh: for the actual 3D representation of the chest
    - pcinventory: representing the contents of the chest (containing 
other entities)
    - pcgravity: if you want the chest to react to gravity and fall down
    - pcmeshselect: so a user can select the mesh with his/her mouse
    - ...
Property classes can be created dynamically and thus you can make 
entities by
adding the appropriate functionality to it.

Property classes communicate to the script or behaviour by sending messages.
For example, the pcinventory property class will send the message 
'pcinventory_addchild'
when something is added to the inventory. The pcmeshselect property class
will send the message 'pcmeshsel_down' if the mouse down button is 
pressed on
the mesh.

How the message is translated to the scripting language is up to the 
plugin that
handles the particular scripting language. For example, in python the 
script is
a python class and every message corresponds directly to a method in 
that class.
So if the property class sends 'pcinventory_addchild' then that method will
be called in the python script.

I have found this system to be very flexible.

Greetings,

Re: [GD-General] Scripting Systems

[Brian H. <ho...@py...>]

> a game. Note that I'm *not* talking about what language to use

Ah, but I will -- anyone using Ruby successfully?  It doesn't seem to 
be particularly well documented for embedding, but it has a host of 
language features that I dig, and Lua and I have a love/hate 
relationship at times.

Brian

[GD-General] Scripting Systems

[Dan T. <da...@ar...>]

I've looked around and implemented a few systems, but I thought I'd get
everyone's opinion on how scripting should be incorporated into a game. Note
that I'm *not* talking about what language to use, or what the scripting
should be used for, nessesarily. Also note that the archives search on
sourceforge is the worst search engine ever known to mankind. If this has
been covered already, I apologize.

The best way I've seen so far is every game object has a script running
behind it that is essentially in an infinite loop. It spins on a check for
messages call into the engine. Then when it gets a message it does stuff.
e.g. Move Forward Was Pressed This Frame message. Then the controlling
script does some trig, comes up with an appropriate force, and calls into
the physics engine to add the force for the object. Also, these scripts run
in a user level thread, where the script manager throttles the script
timeslice based on current game performance, and the scripts call a Yeild()
function when there are no messages to process. (btw, the scripts are
effectively preemtive because we altered the lua execution engine to stop
the stack for a given thread when a certain instruction count is hit. That
way we get many threads, with throttling , and no synchronization issues to
speak of. We also get the ability to limit all scripts to a certain % of
frame time.) The primary downside is with a lot of game objects out there,
you run into some pretty serious dividing of the time you have. Under
release mode, we were getting about 200k lua instructions/second executed in
the time given to the script manager. You get 100 objects in the game, and
you are down to 1k instructions, with isn't a whole lot. This is mediated by
the fact that scripts call a Yeild when they aren't doing anything (so you
get 2 instructions, though both are C calls).

This method is vs. just running a script and creating the stack when the
message comes in. This seemed far too expensive, as you could be creating
script stacks all over the place, and it also runs into the problem where
the game locks because the scripts are being run in the same thread.


These are just the ways I've come up with, and I'd really appreciate some
ideas shot at me on how people think it should be done.

Thanks!
Dan

RE: [GD-General] OS split for UT2003

[Daniel V. <vo...@ep...>]

Take the data for what it's worth though there are two wrong statements in
your post. First, Linux server percentage decreased from 40 to 33 percent
and second, the client percentages are explicitely not current online
numbers but numbers over lifetime like explained in my original post.

> I mean if you don't have the number of players/connections 

Sorry, won't post absolute numbers.

-- Daniel, Epic Games Inc.  

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Toni
> Sent: Tuesday, January 20, 2004 3:56 PM
> To: gam...@li...
> Subject: Re: [GD-General] OS split for UT2003
> 
> Well, even when data is nice to see (i like that linux growth 
> in servers and clients and well, i see the XP shifting too) I 
> think data is not representative.
> I mean if you don't have the number of players/connections 
> whatever you can't compare both data statistics, am i right?. 
> I mean, i don't know how successful UT2003 is but it could be
> easily biassed,  for example because there are less people 
> that plays UT2003 (i don't know that, i've never played 
> ut2003) than in 2002 (that would explain, for example the 
> linux growth, as there are less fps in linux than in windws).
> 
> Just my 2 cents
> 
> Toni
> Lead Designer/Programmer
> insideo.com

Re: [GD-General] OS split for UT2003

[Toni <to...@4d...>]

Well, even when data is nice to see (i like that linux growth in servers 
and clients and well, i see the XP shifting too) I think data is not 
representative.
I mean if you don't have the number of players/connections whatever you 
can't compare both data statistics, am i right?. I mean, i don't know 
how successful UT2003 is but it could be easily biassed,  for example 
because there are less people that plays UT2003 (i don't know that, i've 
never played ut2003) than in 2002 (that would explain, for example the 
linux growth, as there are less fps in linux than in windws).

Just my 2 cents

Toni
Lead Designer/Programmer
insideo.com

[GD-General] OS split for UT2003

[Daniel V. <vo...@ep...>]

Query date 01/08/2004

UT2003      Client      Server

WinXP       75.59 %     27.98 %
Win98/ME    11.08 %      1.32 %
Win2K        9.94 %     35.96 %
Linux/X86    2.07 %     34.03 %
Mac          1.26 %      0.35 %
WinNT        0.04 %      0.01 %

Query date 12/28/2002

UT2003      Client      Server

WinXP       67.78 %     15.62 %
Win98/ME    19.63 %      2.74 %
Win2K       11.87 %     34.96 %
Linux/X86    0.69 %     40.66 %
WinNT        0.00 %      6.03 %

The "server" number is based on current online servers at the time of the
query and the "client" number is based on the last OS used by a CD key that
has been online at least once (aka, connected to our masterserver).

The Mac numbers are not representative for market share as the release
lagged behind by quite a bit and there were also other factors though UT2004
should yield representative numbers as we're shooting for a simultaneous
release.

-- Daniel, Epic Games Inc.

Re: [GD-General] Graphic Library and market share

[Marin K. <m.k...@in...>]

> You should leave your back buffer in video memory and do your rendering 
> into a screen-sized surface in system memory.  Then just copy the 
> sysmem surface to the back buffer every frame.  That gets you back on 

That's pretty much what we were going to do next, except we'll keep
the "real" backbuffer in "raw" system memory (not dd surface) to 
avoid any additional driver issues. Most of our blits are either 
alpha-blended or paletted, so having to blit everything ourselves is
not an issue as we do it anyway.

Thanks,
Marin Kovacic
Lemonade Productions
http://www.lemonade-p.com

Re: [GD-General] Graphic Library and market share

[brian s. <pud...@po...>]

You should leave your back buffer in video memory and do your rendering 
into a screen-sized surface in system memory.  Then just copy the 
sysmem surface to the back buffer every frame.  That gets you back on 
the well-tested driver path, and it isn't any more expensive - you have 
to copy a screen's worth of data from sysmem to vidmem in either case, 
and the flip of the vidmem back buffer to the front is free.

--brian

On Saturday, January 17, 2004, at 07:27  AM, Marin Kovacic wrote:

> However, be careful with this because
> there is a whole range of old nVidia drivers with broken DDraw
> support that exibit rather severe visual glitches when your backbuffer
> is in system memory (which it needs to be for alpha-blending). This
> has been an endless source of pain for us.

Re: [GD-General] Graphic Library and market share

[Marin K. <m.k...@in...>]

> Oh, and for the market share - here are our web stats for January.
> It's not a lot of traffic, but should be somewhat statisticaly relevant:
>     Operating System   Hits   Visitors   % of Total Visitors
>  1   Windows XP     30,219   6,296   59.71%
>  2   Windows 98     7,922   1,848   17.52%
>  3   Windows 2000    6,953   1,042   9.88%
>  4   Windows ME     2,582   675   6.40%

Actualy, now that I look at these figures I believe they are skewed
towards WinXP a bit. Usually they look more like this (stats
for October):

    Operating System   Hits   Visitors   % of Total Visitors  
 1   Windows XP     12,639   2,154   47.63%  
 2   Windows 98     6,592   1,057   23.37%  
 3   Windows 2000    2,549   427   9.44%  
 4   Others     1,010   360   7.96%  
 5   Windows ME     1,882   352   7.78%  
 6   Windows NT    563   69   1.53%  

-- 
Marin Kovacic
Lemonade Productions
http://www.lemonade-p.com

Re: [GD-General] Graphic Library and market share

[Marin K. <m.k...@in...>]

> DirectX. I believe DX8.1 comes with Windows XP, and at least DX6 or DX7
> must come with W2K. We don't care a lot about W98 right now (¿Should
> we?). Our programmers say DX8 will be easier to use tan DX7, but I'm
> worried it will restrict our market share, as we're not targeting
> hardcore gamers (with the latest in machine and OS).

Oh, and for the market share - here are our web stats for January.
It's not a lot of traffic, but should be somewhat statisticaly relevant:

    Operating System   Hits   Visitors   % of Total Visitors
 1   Windows XP     30,219   6,296   59.71%
 2   Windows 98     7,922   1,848   17.52%
 3   Windows 2000    6,953   1,042   9.88%
 4   Windows ME     2,582   675   6.40%
 5   Others     1,625   414   3.93%
 6   Windows NT     660   120   1.14%
 7   Windows 95     157   56   0.53%
 8   Mac OS     647   47   0.45%
 9   Linux     204   28   0.27%
 10   Windows Win32s    24   15   0.14%
 11   FreeBSD     2   2   0.02%
 12   MSN TV   (WebTV)   1   1   0.01%
 13   Sun OS     1   1   0.01%

--
Marin Kovacic
Lemonade Productions
http://www.lemonade-p.com

Re: [GD-General] Graphic Library and market share

[Marin K. <m.k...@in...>]

>    We're making some small puzzle game for Win32 to be (hopefully)
> distributed online. We're currently using SDL (as we had planned to make
> it easily portable), but some problems with it are slowing down our
> development (timer granularity and slow alpha blitting mostly).
>    So we're thinking in using DirectX for now, and later care about
> other platforms. I wanted to get some idea about the installed base of
> DirectX. I believe DX8.1 comes with Windows XP, and at least DX6 or DX7
> must come with W2K. We don't care a lot about W98 right now (¿Should
> we?). Our programmers say DX8 will be easier to use tan DX7, but I'm
> worried it will restrict our market share, as we're not targeting
> hardcore gamers (with the latest in machine and OS).

If you're going to use DDraw then you're using DX7 anyway, and it
comes with W2k, AFAIK. However, be careful with this because
there is a whole range of old nVidia drivers with broken DDraw
support that exibit rather severe visual glitches when your backbuffer
is in system memory (which it needs to be for alpha-blending). This
has been an endless source of pain for us.

If I was rewriting our stuff today, I'd ditch any hw-accel altogether
and go with GDI, or *possibly* require 3d hw and go with D3D8.

Regards,
Marin Kovacic
Lemonade Productions
http://www.lemonade-p.com

Re: [GD-General] NAT Negotiation

[Aaron D. <ri...@in...>]

> Right.  However an 85% solution covers a heck of a lot of bases,
> especially when you can just throw in a few retries to whittle down that
> 15% failure mode to something consumer-grade acceptable.

What can I say? I'm amazed... I would never have attemped anything like this 
and I suprised that software like gamespy has as well but heck... What a big 
hack!

In this case, take back my last linux-related post stating it won't work 
because linux uses incremental port numbers (with reuse of disconnected 
ports) and its highly likely that such a hack might work... 

I still can't help but dislike it however.... :)

Re: [GD-General] NAT Negotiation

[J C L. <cl...@ka...>]

On Tue, 13 Jan 2004 09:48:36 +1100 
Aaron Drew <ri...@in...> wrote:
> On Mon, 12 Jan 2004 10:49 pm, Magnus Auvinen wrote:

>> Now the C1 and C2 can communicate with each other. I don't know if
>> this works because of the assumption at point 4. You could perhaps
>> use some other algorithm to predict what port will be the next one
>> (don't have PP installed so I can't look at the .ppt file).

> This is a *BAD* idea. I know that Linux doesn't just use the local
> port number for NAT connections but also the external destination
> address and destination port number. This is the most correct way to
> operate (especially from a security point of view) and any NAT
> implementation that relies on anything less (such as _only_ the local
> port number as you suggest) is clearly broken and should NOT be relied
> upon.

It is a bad but surprisingly reliable idea.  It is also a hack.  Loosely
it comes down to:

  Client1 sends packet to server.  Server notes port etc.

  Client2 sends packet to server.  Server notes port etc.

  Server predicts the next port which will allocated by the NAT devices
  for Client1 and Client2 and instructs each client to start sending a
  packet stream to the other's NAT device at the predicted port.

If the prediction was successful after a few packets each way (so that
each end creates a port mapping) two way communication through the NAT
boxes will be in place.  If the prediction was unsuccessful they'll
either have to try again or fail.  

This is exactly what GameSpy and similar products do.  Frankly they
usually do it by taking the new port number allocated by the test packet
stream to the server and incrementing it by one to get the predicted
port for the next port allocation.  Simple, dumb, surprisingly
effective.

> The ONLY reliable way to do this is to have some mutually accessible
> server in the middle and use it to explicitly relay traffic between
> NATed clients.

Right.  However an 85% solution covers a heck of a lot of bases,
especially when you can just throw in a few retries to whittle down that
15% failure mode to something consumer-grade acceptable.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] NAT Negotiation

[J C L. <cl...@ka...>]

On Tue, 13 Jan 2004 07:30:58 +0800 
Brett Bibby <res...@ga...> wrote:

> I believe some NATs will increment port numbers and that would be a
> good guess to try, but I also read that they may assign random port
> numbers. Seems pretty hard to establish a connection to a NAT device
> randomly generating port numbers. Hmmm...

Every cheap consumer grade low margin NAT box I've examined (roughly a
dozen) has used a base algorithm of simply incrementing the last
allocated port.  Some of them tweak this by periodically/variously
stuffing old reclaimed ports back in the available list or some other
port recycling pattern, but that's the exception rather than the rule,
and a simple retry reduces it to pretty near a 0% margin.

Higher end NAT boxes however have all sorts of tricks and behaviours.
They allocate seemingly randomly, or with ports as members of a hash
function of the address, or some other curiosity, usually in the name of
scalability or performance.  Some low end boxes do this as well (and no,
I can't quote as I'm a long way from home and my files right now), but
it isn't common at the lower ends.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] NAT Negotiation

[Brett B. <res...@ga...>]

This is what everybody does pretty much. The link I included in my =
previous reply is a good rxplanation of the issues invoilved ( =
http://www.mindcontrol.org/~hplus/nat-punch.html )

I believe some NATs will increment port numbers and that would be a good =
guess to try, but I also read that they may assign random port numbers. =
Seems pretty hard to establish a connection to a NAT device randomly =
generating port numbers. Hmmm...

----- Original Message -----=20
From: "Magnus Auvinen" <mag...@st...>
To: <gam...@li...>
Sent: Monday, January 12, 2004 7:49 PM
Subject: RE: [GD-General] NAT Negotiation


> If I've understand this correctly you have two clients (named C1 and =
C2)
> behind NAT connected to a server (named S) and you want to establish a
> connection between the two clients without reconfiguring the NAT =
server.
> I've thought about this problem and I've come up with a solution that =
may
> work.
>=20
> 1. C1 decides that it want to establish a connection between itself =
and C2
> so it send that request to S. 2. S starts listening to two new ports =
and
> sends one of the numbers to C1 and the other C2. 3. C1 and C2 respond =
to
> this packet. 4. S now have the current port numbers of the two clients =
NAT.
> Assuming that the NAT will give the next "connection" a port one step =
higher
> then this it sends out C2 port number+1 to C1 and vice versa. 5. C1 =
and C2
> starts sending each other packets (about 3-5 with 100ms delay should =
be
> enough) on the assigned ports from the server until they get a =
response.
>=20
> Now the C1 and C2 can communicate with each other. I don't know if =
this
> works because of the assumption at point 4. You could perhaps use some =
other
> algorithm to predict what port will be the next one (don't have PP =
installed
> so I can't look at the .ppt file). Another problem is if the NAT is =
under a
> lot of pressure a lot of new entries will be made in the dynamic =
routing
> table so the assumption fails, but the procedure can be repeated until
> success. Also, if the NAT is smart it can refuse to use a port that =
has data
> that has been transmitted to it recently. This means that at point 5 =
the
> client must send the packets at the same time within one half of a =
RTT. A
> lot of problems but this are the only way I found to solve the =
problem.
> =20
> Please try it if you want. I don't know if it works. Perhaps there are
> better ways to solve it.
>=20
> :)
>=20
> .magnus auvinen
>=20
> -----Original Message-----
> From: Brett Bibby [mailto:res...@ga...]=20
> Sent: den 12 januari 2004 09:18
> To: Gam...@li...
> Subject: [GD-General] NAT Negotiation
>=20
>=20
> This thread is being transferred form the GD-Algorithms list as Brian
> pointed out it may be OT for the algorithms list. I apologize if this
> attempt to transfer doesn't go well :-)
>=20
> **Original Post**
>=20
> Yet another network post <sigh>...
>=20
> I searched the archives for NAT and came up with 14 posts. Some say =
NAT is a
> problem, others say it's no problem especially when using a third =
server
> connected directly to the internet. Google results in a number of old =
pages,
> many with outdated links. My problem is that I need to come up with =
some
> sort of internal NAT solution (if it's really needed?) because we need =
to
> support multiple platforms, and I cannot find any third party solution
> (including Gamespy or open source) that covers all the platforms or
> compilable for them.
>=20
> Let's say I have two machines, both behind NATs. They both think their
> address is 192.168.1.100, but to the outside world it's =
123.123.123.123 and
> 124.124.124.124 (whatever). The only way for these two machines to =
ever find
> each other is through some third party, and they are at =
125.125.125.125.
>=20
> They each get their address locally (192.168.1.100) and send that to =
the
> server in a packet it can understand. The server reads the packet and =
also
> notes the ip address of the received packet, so now the server has =
both the
> public and private address of a given client. It then sends each of =
the
> clients the other's address(es) and they try to contact each other.
>=20
> Is this correct so far? Does it work because the NAT assigned =
different
> internal port numbers to the outgoing requests so it uses that to =
route the
> incoming packets back to the requestor? If so, this seems deceptively
> simple. Why does Gamespy mention they have to do other things too?
>=20
> http://www.igda.org/oc/IGDAGamespyNAT.ppt
>=20
> In a slide near the end they say they do some port guessing based upon
> common patterns. Why would they need this if a third party server is =
used?
>=20
> Also, Brian Hook mentions in one of his posts in the archive about =
using the
> lower 16 bits of the ip address as a unique identifier. Why would I =
need to
> do this?
>=20
> http://sourceforge.net/mailarchive/message.php?msg_id=3D3667950
>=20
> There is also a mention that you shouldn't hard code port numbers. Is =
there
> a recommended way to generate one?
>=20
> Finally, what if I am playing a game where two of us are behind a NAT =
on a
> LAN but connected to the same game on the internet. It's likely that I =
would
> recieve an address from the server of some other player's private =
address
> that would coincide with the address of my friend. When I contact them =
at
> that address they reply and I get the wrong connection. Is this what =
Brian
> was using the low 16 bits as an identifier for in order to distinguish
> between people using the same private address accidentally contacting
> another machine on their LAN?
>=20
> Thanks
> Brett
>=20
> ** End Original Post **
> ** Reply by Brian Hook**
>=20
> This is precariously on the border of being OT and should probably be=20
> handled on gd-general, but I don't think it's flagrant (but it's Tom's =

> list, so if he disagrees, we can take it to gd-general)
>=20
> > I searched the archives for NAT and came up with 14 posts. Some say
> > NAT is a problem, others say it's no problem especially when using
>=20
> NAT is not a problem if you know what you're doing.  That's not meant=20
> to be flippant or derogatory, but only to point out that A.) it's a=20
> hairy problem to the uninitiated and B.) it's a solvable problem.
>=20
> > They each get their address locally (192.168.1.100) and send that
> > to the server in a packet it can understand. The server reads the
> > packet and also notes the ip address of the received packet, so now
> > the server has both the public and private address of a given
> > client. It then sends each of the clients the other's address(es)
> > and they try to contact each other.
>=20
> Sounds about right.
>=20
> > Is this correct so far? Does it work because the NAT assigned
> > different internal port numbers to the outgoing requests so it uses
> > that to route the incoming packets back to the requestor?
>=20
> Yes, but you can't rely on this.  UDP is a connectionless protocol, so =

> in _theory_ (but rarely in practice, at least in the past 5 years or=20
> so), the reverse port mapping can change on a per packet basis.  This=20
> is described in a bit more detail in my article on multiplayer=20
> programming you can find at bookofhook.com
>=20
> > In a slide near the end they say they do some port guessing based
> > upon common patterns. Why would they need this if a third party
> > server is used?
>=20
> What they're trying to do is allow two players to connect to each=20
> other _without opening up any ports_.  At least, that's my=20
> understanding.  This avoids the entire "explaining to users how NAT=20
> works and why they can't host a server" problem.
>=20
> > Also, Brian Hook mentions in one of his posts in the archive about
> > using the lower 16 bits of the ip address as a unique identifier.
> > Why would I need to do this?
>=20
> To resolve clients behind a NAT.
>=20
> > There is also a mention that you shouldn't hard code port numbers.
> > Is there a recommended way to generate one?
>=20
> Which port numbers?  For your server, you should hardcode them (so=20
> that you can tell users what ports to open/forward) but you should=20
> also allow them to be relocated in case there's a conflict.
>=20
> > Finally, what if I am playing a game where two of us are behind a
> > NAT on a LAN but connected to the same game on the internet. It's
> > likely that I would recieve an address from the server of some
> > other player's private address that would coincide with the address
> > of my friend.=20
>=20
> No, you'll receive the other person's _public_ address and port=20
> mapping (ideally) that allows you to communicate with them directly. =20
> At least, that's what I'm assuming they're trying to do.  If you=20
> received 192.168.1.100, well, that's not too helpful since it'll just=20
> route to your own internal network (on a router that uses that=20
> mapping).
>=20
> Brian
>=20
> **End Brian Hook's Reply**
> **Begin Second Post**
>=20
> > This is precariously on the border of being OT and should probably =
be=20
> > handled on gd-general, but I don't think it's flagrant (but it's =
Tom's=20
> > list, so if he disagrees, we can take it to gd-general)
>=20
> I posted it here since there was discussion before on this list with =
no
> mention of OT at that time. Let me know if you want it moved to =
GD-General
> and I will do so immediately.
>=20
> > What they're trying to do is allow two players to connect to each=20
> > other _without opening up any ports_.  At least, that's my=20
> > understanding.  This avoids the entire "explaining to users how NAT=20
> > works and why they can't host a server" problem.
>=20
> Couldn't they host a server as long as the third party matchmaking =
server
> game out thier public ip? Or is the rarely changing port number the =
problem
> here too? There isn't much difference between a client and a server =
once the
> third party matchmaking knows the correct ip and port number is there?
>=20
> >=20
> > > Also, Brian Hook mentions in one of his posts in the archive about
> > > using the lower 16 bits of the ip address as a unique identifier.
> > > Why would I need to do this?
> >=20
> > To resolve clients behind a NAT.
> >=20
>=20
> So this number would be used to identify players internally rather =
than
> ip/port, and when I want to send the packet I lookup the ip/port based =
upon
> this?
> =20
> > > Finally, what if I am playing a game where two of us are behind a
> > > NAT on a LAN but connected to the same game on the internet. It's
> > > likely that I would recieve an address from the server of some
> > > other player's private address that would coincide with the =
address
> > > of my friend.=20
> >=20
> > No, you'll receive the other person's _public_ address and port=20
> > mapping (ideally) that allows you to communicate with them directly. =
=20
> > At least, that's what I'm assuming they're trying to do.  If you=20
> > received 192.168.1.100, well, that's not too helpful since it'll =
just=20
> > route to your own internal network (on a router that uses that=20
> > mapping).
> >=20
>=20
> Is this correct? So if I'm behind the same NAT as my friend, will the =
router
> detect the outgoing public ip address and port and reroute it back =
inside
> directly to them?
>=20
> Brett
>=20
> ** End Second Post**
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

Re: [GD-General] NAT Negotiation

[Brett B. <res...@ga...>]

> This post seems like you are making the topic more complex than it =
really=20
> should be.=20

Sadly, no :-)

> So, if you have a simple protocol in which all connections originate =
from=20
> _behind_ the NAT device, destined for the server, you won't have any =
issues.=20

The problem is with peer-to-peer. The NAT opened a hole for the server, =
but not for another client who is also behind a NAT. Even if both =
clients send each other packets on the same port, there is no guarantee =
that the specified port may open up. It could be random, incremented one =
or some other algorithm.

Check out http://www.mindcontrol.org/~hplus/nat-punch.html for a nicer =
explanation of the issues.

RE: [GD-General] NAT Negotiation

[Neil S. <ne...@r0...>]

Isn't UPnP NAT Traversal supposed to be the solution to these issues?

- Neil.
 

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Aaron Drew
> Sent: 12 January 2004 10:49 PM
> To: gam...@li...
> Subject: Re: [GD-General] NAT Negotiation
> 
> On Mon, 12 Jan 2004 10:49 pm, Magnus Auvinen wrote:
> > Now the C1 and C2 can communicate with each other. I don't know if 
> > this works because of the assumption at point 4. You could 
> perhaps use 
> > some other algorithm to predict what port will be the next 
> one (don't 
> > have PP installed so I can't look at the .ppt file).
> 
> This is a *BAD* idea. I know that Linux doesn't just use the 
> local port number for NAT connections but also the external 
> destination address and destination port number. This is the 
> most correct way to operate (especially from a security point 
> of view) and any NAT implementation that relies on anything 
> less (such as _only_ the local port number as you suggest) is 
> clearly broken and should NOT be relied upon.
> 
> The ONLY reliable way to do this is to have some mutually 
> accessible server in the middle and use it to explicitly 
> relay traffic between NATed clients. 
> 
> For the more educated users, port forwarding on the NAT 
> device can allow incoming connections in but there is 
> currently no (universal) NAT technology that allows a client 
> to open a listening socket on the NAT device. The closest 
> technology I can think of is Windows connection sharing but 
> you won't find that being used in 95% of all NAT devices on 
> the Internet (most will be ADSL/Cable modems).
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System 
> offering advanced branching capabilities and atomic changes 
> on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] NAT Negotiation

[Aaron D. <ri...@in...>]

On Mon, 12 Jan 2004 10:49 pm, Magnus Auvinen wrote:
> Now the C1 and C2 can communicate with each other. I don't know if this
> works because of the assumption at point 4. You could perhaps use some
> other algorithm to predict what port will be the next one (don't have PP
> installed so I can't look at the .ppt file). 

This is a *BAD* idea. I know that Linux doesn't just use the local port number 
for NAT connections but also the external destination address and destination 
port number. This is the most correct way to operate (especially from a 
security point of view) and any NAT implementation that relies on anything 
less (such as _only_ the local port number as you suggest) is clearly broken 
and should NOT be relied upon.

The ONLY reliable way to do this is to have some mutually accessible server in 
the middle and use it to explicitly relay traffic between NATed clients. 

For the more educated users, port forwarding on the NAT device can allow 
incoming connections in but there is currently no (universal) NAT technology 
that allows a client to open a listening socket on the NAT device. The 
closest technology I can think of is Windows connection sharing but you won't 
find that being used in 95% of all NAT devices on the Internet (most will be 
ADSL/Cable modems).

RE: [GD-General] NAT Negotiation

[Magnus A. <mag...@st...>]

If I've understand this correctly you have two clients (named C1 and C2)
behind NAT connected to a server (named S) and you want to establish a
connection between the two clients without reconfiguring the NAT server.
I've thought about this problem and I've come up with a solution that may
work.

1. C1 decides that it want to establish a connection between itself and C2
so it send that request to S. 2. S starts listening to two new ports and
sends one of the numbers to C1 and the other C2. 3. C1 and C2 respond to
this packet. 4. S now have the current port numbers of the two clients NAT.
Assuming that the NAT will give the next "connection" a port one step higher
then this it sends out C2 port number+1 to C1 and vice versa. 5. C1 and C2
starts sending each other packets (about 3-5 with 100ms delay should be
enough) on the assigned ports from the server until they get a response.

Now the C1 and C2 can communicate with each other. I don't know if this
works because of the assumption at point 4. You could perhaps use some other
algorithm to predict what port will be the next one (don't have PP installed
so I can't look at the .ppt file). Another problem is if the NAT is under a
lot of pressure a lot of new entries will be made in the dynamic routing
table so the assumption fails, but the procedure can be repeated until
success. Also, if the NAT is smart it can refuse to use a port that has data
that has been transmitted to it recently. This means that at point 5 the
client must send the packets at the same time within one half of a RTT. A
lot of problems but this are the only way I found to solve the problem.
 
Please try it if you want. I don't know if it works. Perhaps there are
better ways to solve it.

:)

.magnus auvinen

-----Original Message-----
From: Brett Bibby [mailto:res...@ga...] 
Sent: den 12 januari 2004 09:18
To: Gam...@li...
Subject: [GD-General] NAT Negotiation


This thread is being transferred form the GD-Algorithms list as Brian
pointed out it may be OT for the algorithms list. I apologize if this
attempt to transfer doesn't go well :-)

**Original Post**

Yet another network post <sigh>...

I searched the archives for NAT and came up with 14 posts. Some say NAT is a
problem, others say it's no problem especially when using a third server
connected directly to the internet. Google results in a number of old pages,
many with outdated links. My problem is that I need to come up with some
sort of internal NAT solution (if it's really needed?) because we need to
support multiple platforms, and I cannot find any third party solution
(including Gamespy or open source) that covers all the platforms or
compilable for them.

Let's say I have two machines, both behind NATs. They both think their
address is 192.168.1.100, but to the outside world it's 123.123.123.123 and
124.124.124.124 (whatever). The only way for these two machines to ever find
each other is through some third party, and they are at 125.125.125.125.

They each get their address locally (192.168.1.100) and send that to the
server in a packet it can understand. The server reads the packet and also
notes the ip address of the received packet, so now the server has both the
public and private address of a given client. It then sends each of the
clients the other's address(es) and they try to contact each other.

Is this correct so far? Does it work because the NAT assigned different
internal port numbers to the outgoing requests so it uses that to route the
incoming packets back to the requestor? If so, this seems deceptively
simple. Why does Gamespy mention they have to do other things too?

http://www.igda.org/oc/IGDAGamespyNAT.ppt

In a slide near the end they say they do some port guessing based upon
common patterns. Why would they need this if a third party server is used?

Also, Brian Hook mentions in one of his posts in the archive about using the
lower 16 bits of the ip address as a unique identifier. Why would I need to
do this?

http://sourceforge.net/mailarchive/message.php?msg_id=3667950

There is also a mention that you shouldn't hard code port numbers. Is there
a recommended way to generate one?

Finally, what if I am playing a game where two of us are behind a NAT on a
LAN but connected to the same game on the internet. It's likely that I would
recieve an address from the server of some other player's private address
that would coincide with the address of my friend. When I contact them at
that address they reply and I get the wrong connection. Is this what Brian
was using the low 16 bits as an identifier for in order to distinguish
between people using the same private address accidentally contacting
another machine on their LAN?

Thanks
Brett

** End Original Post **
** Reply by Brian Hook**

This is precariously on the border of being OT and should probably be 
handled on gd-general, but I don't think it's flagrant (but it's Tom's 
list, so if he disagrees, we can take it to gd-general)

> I searched the archives for NAT and came up with 14 posts. Some say
> NAT is a problem, others say it's no problem especially when using

NAT is not a problem if you know what you're doing.  That's not meant 
to be flippant or derogatory, but only to point out that A.) it's a 
hairy problem to the uninitiated and B.) it's a solvable problem.

> They each get their address locally (192.168.1.100) and send that
> to the server in a packet it can understand. The server reads the
> packet and also notes the ip address of the received packet, so now
> the server has both the public and private address of a given
> client. It then sends each of the clients the other's address(es)
> and they try to contact each other.

Sounds about right.

> Is this correct so far? Does it work because the NAT assigned
> different internal port numbers to the outgoing requests so it uses
> that to route the incoming packets back to the requestor?

Yes, but you can't rely on this.  UDP is a connectionless protocol, so 
in _theory_ (but rarely in practice, at least in the past 5 years or 
so), the reverse port mapping can change on a per packet basis.  This 
is described in a bit more detail in my article on multiplayer 
programming you can find at bookofhook.com

> In a slide near the end they say they do some port guessing based
> upon common patterns. Why would they need this if a third party
> server is used?

What they're trying to do is allow two players to connect to each 
other _without opening up any ports_.  At least, that's my 
understanding.  This avoids the entire "explaining to users how NAT 
works and why they can't host a server" problem.

> Also, Brian Hook mentions in one of his posts in the archive about
> using the lower 16 bits of the ip address as a unique identifier.
> Why would I need to do this?

To resolve clients behind a NAT.

> There is also a mention that you shouldn't hard code port numbers.
> Is there a recommended way to generate one?

Which port numbers?  For your server, you should hardcode them (so 
that you can tell users what ports to open/forward) but you should 
also allow them to be relocated in case there's a conflict.

> Finally, what if I am playing a game where two of us are behind a
> NAT on a LAN but connected to the same game on the internet. It's
> likely that I would recieve an address from the server of some
> other player's private address that would coincide with the address
> of my friend. 

No, you'll receive the other person's _public_ address and port 
mapping (ideally) that allows you to communicate with them directly.  
At least, that's what I'm assuming they're trying to do.  If you 
received 192.168.1.100, well, that's not too helpful since it'll just 
route to your own internal network (on a router that uses that 
mapping).

Brian

**End Brian Hook's Reply**
**Begin Second Post**

> This is precariously on the border of being OT and should probably be 
> handled on gd-general, but I don't think it's flagrant (but it's Tom's 
> list, so if he disagrees, we can take it to gd-general)

I posted it here since there was discussion before on this list with no
mention of OT at that time. Let me know if you want it moved to GD-General
and I will do so immediately.

> What they're trying to do is allow two players to connect to each 
> other _without opening up any ports_.  At least, that's my 
> understanding.  This avoids the entire "explaining to users how NAT 
> works and why they can't host a server" problem.

Couldn't they host a server as long as the third party matchmaking server
game out thier public ip? Or is the rarely changing port number the problem
here too? There isn't much difference between a client and a server once the
third party matchmaking knows the correct ip and port number is there?

> 
> > Also, Brian Hook mentions in one of his posts in the archive about
> > using the lower 16 bits of the ip address as a unique identifier.
> > Why would I need to do this?
> 
> To resolve clients behind a NAT.
> 

So this number would be used to identify players internally rather than
ip/port, and when I want to send the packet I lookup the ip/port based upon
this?
 
> > Finally, what if I am playing a game where two of us are behind a
> > NAT on a LAN but connected to the same game on the internet. It's
> > likely that I would recieve an address from the server of some
> > other player's private address that would coincide with the address
> > of my friend. 
> 
> No, you'll receive the other person's _public_ address and port 
> mapping (ideally) that allows you to communicate with them directly.  
> At least, that's what I'm assuming they're trying to do.  If you 
> received 192.168.1.100, well, that's not too helpful since it'll just 
> route to your own internal network (on a router that uses that 
> mapping).
> 

Is this correct? So if I'm behind the same NAT as my friend, will the router
detect the outgoing public ip address and port and reroute it back inside
directly to them?

Brett

** End Second Post**


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] NAT Negotiation

[Aaron D. <ri...@in...>]

This post seems like you are making the topic more complex than it really 
should be. 

NAT will typically take any _outgoing_ connection request, add it to a table 
on the NAT device, map the internal IP and port it to some external port 
(typically > 32000) on the NAT device, mangle the packet and sending. It  
performs the reverse translation for incoming data and most NAT devices 
support both TCP and UDP these days.

So, if you have a simple protocol in which all connections originate from 
_behind_ the NAT device, destined for the server, you won't have any issues. 
If you require connections that are initiated by the server or other clients 
however, you will run into trouble because (for fairly obvious reasons) 
sending packets to the NAT device for connections that are NOT in the NAT's 
table will not get them to the client machine.

On Mon, 12 Jan 2004 07:17 pm, Brett Bibby wrote:
> This thread is being transferred form the GD-Algorithms list as Brian
> pointed out it may be OT for the algorithms list. I apologize if this
> attempt to transfer doesn't go well :-)
>
> **Original Post**
>
> Yet another network post <sigh>...
>
> I searched the archives for NAT and came up with 14 posts. Some say NAT is
> a problem, others say it's no problem especially when using a third server
> connected directly to the internet. Google results in a number of old
> pages, many with outdated links. My problem is that I need to come up with
> some sort of internal NAT solution (if it's really needed?) because we need
> to support multiple platforms, and I cannot find any third party solution
> (including Gamespy or open source) that covers all the platforms or
> compilable for them.
>
> Let's say I have two machines, both behind NATs. They both think their
> address is 192.168.1.100, but to the outside world it's 123.123.123.123 and
> 124.124.124.124 (whatever). The only way for these two machines to ever
> find each other is through some third party, and they are at
> 125.125.125.125.
>
> They each get their address locally (192.168.1.100) and send that to the
> server in a packet it can understand. The server reads the packet and also
> notes the ip address of the received packet, so now the server has both the
> public and private address of a given client. It then sends each of the
> clients the other's address(es) and they try to contact each other.
>
> Is this correct so far? Does it work because the NAT assigned different
> internal port numbers to the outgoing requests so it uses that to route the
> incoming packets back to the requestor? If so, this seems deceptively
> simple. Why does Gamespy mention they have to do other things too?
>
> http://www.igda.org/oc/IGDAGamespyNAT.ppt
>
> In a slide near the end they say they do some port guessing based upon
> common patterns. Why would they need this if a third party server is used?
>
> Also, Brian Hook mentions in one of his posts in the archive about using
> the lower 16 bits of the ip address as a unique identifier. Why would I
> need to do this?
>
> http://sourceforge.net/mailarchive/message.php?msg_id=3667950
>
> There is also a mention that you shouldn't hard code port numbers. Is there
> a recommended way to generate one?
>
> Finally, what if I am playing a game where two of us are behind a NAT on a
> LAN but connected to the same game on the internet. It's likely that I
> would recieve an address from the server of some other player's private
> address that would coincide with the address of my friend. When I contact
> them at that address they reply and I get the wrong connection. Is this
> what Brian was using the low 16 bits as an identifier for in order to
> distinguish between people using the same private address accidentally
> contacting another machine on their LAN?
>
> Thanks
> Brett
>
> ** End Original Post **
> ** Reply by Brian Hook**
>
> This is precariously on the border of being OT and should probably be
> handled on gd-general, but I don't think it's flagrant (but it's Tom's
> list, so if he disagrees, we can take it to gd-general)
>
> > I searched the archives for NAT and came up with 14 posts. Some say
> > NAT is a problem, others say it's no problem especially when using
>
> NAT is not a problem if you know what you're doing.  That's not meant
> to be flippant or derogatory, but only to point out that A.) it's a
> hairy problem to the uninitiated and B.) it's a solvable problem.
>
> > They each get their address locally (192.168.1.100) and send that
> > to the server in a packet it can understand. The server reads the
> > packet and also notes the ip address of the received packet, so now
> > the server has both the public and private address of a given
> > client. It then sends each of the clients the other's address(es)
> > and they try to contact each other.
>
> Sounds about right.
>
> > Is this correct so far? Does it work because the NAT assigned
> > different internal port numbers to the outgoing requests so it uses
> > that to route the incoming packets back to the requestor?
>
> Yes, but you can't rely on this.  UDP is a connectionless protocol, so
> in _theory_ (but rarely in practice, at least in the past 5 years or
> so), the reverse port mapping can change on a per packet basis.  This
> is described in a bit more detail in my article on multiplayer
> programming you can find at bookofhook.com
>
> > In a slide near the end they say they do some port guessing based
> > upon common patterns. Why would they need this if a third party
> > server is used?
>
> What they're trying to do is allow two players to connect to each
> other _without opening up any ports_.  At least, that's my
> understanding.  This avoids the entire "explaining to users how NAT
> works and why they can't host a server" problem.
>
> > Also, Brian Hook mentions in one of his posts in the archive about
> > using the lower 16 bits of the ip address as a unique identifier.
> > Why would I need to do this?
>
> To resolve clients behind a NAT.
>
> > There is also a mention that you shouldn't hard code port numbers.
> > Is there a recommended way to generate one?
>
> Which port numbers?  For your server, you should hardcode them (so
> that you can tell users what ports to open/forward) but you should
> also allow them to be relocated in case there's a conflict.
>
> > Finally, what if I am playing a game where two of us are behind a
> > NAT on a LAN but connected to the same game on the internet. It's
> > likely that I would recieve an address from the server of some
> > other player's private address that would coincide with the address
> > of my friend.
>
> No, you'll receive the other person's _public_ address and port
> mapping (ideally) that allows you to communicate with them directly.
> At least, that's what I'm assuming they're trying to do.  If you
> received 192.168.1.100, well, that's not too helpful since it'll just
> route to your own internal network (on a router that uses that
> mapping).
>
> Brian
>
> **End Brian Hook's Reply**
> **Begin Second Post**
>
> > This is precariously on the border of being OT and should probably be
> > handled on gd-general, but I don't think it's flagrant (but it's Tom's
> > list, so if he disagrees, we can take it to gd-general)
>
> I posted it here since there was discussion before on this list with no
> mention of OT at that time. Let me know if you want it moved to GD-General
> and I will do so immediately.
>
> > What they're trying to do is allow two players to connect to each
> > other _without opening up any ports_.  At least, that's my
> > understanding.  This avoids the entire "explaining to users how NAT
> > works and why they can't host a server" problem.
>
> Couldn't they host a server as long as the third party matchmaking server
> game out thier public ip? Or is the rarely changing port number the problem
> here too? There isn't much difference between a client and a server once
> the third party matchmaking knows the correct ip and port number is there?
>
> > > Also, Brian Hook mentions in one of his posts in the archive about
> > > using the lower 16 bits of the ip address as a unique identifier.
> > > Why would I need to do this?
> >
> > To resolve clients behind a NAT.
>
> So this number would be used to identify players internally rather than
> ip/port, and when I want to send the packet I lookup the ip/port based upon
> this?
>
> > > Finally, what if I am playing a game where two of us are behind a
> > > NAT on a LAN but connected to the same game on the internet. It's
> > > likely that I would recieve an address from the server of some
> > > other player's private address that would coincide with the address
> > > of my friend.
> >
> > No, you'll receive the other person's _public_ address and port
> > mapping (ideally) that allows you to communicate with them directly.
> > At least, that's what I'm assuming they're trying to do.  If you
> > received 192.168.1.100, well, that's not too helpful since it'll just
> > route to your own internal network (on a router that uses that
> > mapping).
>
> Is this correct? So if I'm behind the same NAT as my friend, will the
> router detect the outgoing public ip address and port and reroute it back
> inside directly to them?
>
> Brett
>
> ** End Second Post**
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

-- 
- Aaron

"Today's mighty oak is just yesterday's nut that held its ground."

[GD-General] NAT Negotiation

[Brett B. <res...@ga...>]

This thread is being transferred form the GD-Algorithms list as Brian =
pointed out it may be OT for the algorithms list. I apologize if this =
attempt to transfer doesn't go well :-)

**Original Post**

Yet another network post <sigh>...

I searched the archives for NAT and came up with 14 posts. Some say NAT =
is a problem, others say it's no problem especially when using a third =
server connected directly to the internet. Google results in a number of =
old pages, many with outdated links. My problem is that I need to come =
up with some sort of internal NAT solution (if it's really needed?) =
because we need to support multiple platforms, and I cannot find any =
third party solution (including Gamespy or open source) that covers all =
the platforms or compilable for them.

Let's say I have two machines, both behind NATs. They both think their =
address is 192.168.1.100, but to the outside world it's 123.123.123.123 =
and 124.124.124.124 (whatever). The only way for these two machines to =
ever find each other is through some third party, and they are at =
125.125.125.125.

They each get their address locally (192.168.1.100) and send that to the =
server in a packet it can understand. The server reads the packet and =
also notes the ip address of the received packet, so now the server has =
both the public and private address of a given client. It then sends =
each of the clients the other's address(es) and they try to contact each =
other.

Is this correct so far? Does it work because the NAT assigned different =
internal port numbers to the outgoing requests so it uses that to route =
the incoming packets back to the requestor? If so, this seems =
deceptively simple. Why does Gamespy mention they have to do other =
things too?

http://www.igda.org/oc/IGDAGamespyNAT.ppt

In a slide near the end they say they do some port guessing based upon =
common patterns. Why would they need this if a third party server is =
used?

Also, Brian Hook mentions in one of his posts in the archive about using =
the lower 16 bits of the ip address as a unique identifier. Why would I =
need to do this?

http://sourceforge.net/mailarchive/message.php?msg_id=3D3667950

There is also a mention that you shouldn't hard code port numbers. Is =
there a recommended way to generate one?

Finally, what if I am playing a game where two of us are behind a NAT on =
a LAN but connected to the same game on the internet. It's likely that I =
would recieve an address from the server of some other player's private =
address that would coincide with the address of my friend. When I =
contact them at that address they reply and I get the wrong connection. =
Is this what Brian was using the low 16 bits as an identifier for in =
order to distinguish between people using the same private address =
accidentally contacting another machine on their LAN?

Thanks
Brett

** End Original Post **
** Reply by Brian Hook**

This is precariously on the border of being OT and should probably be=20
handled on gd-general, but I don't think it's flagrant (but it's Tom's=20
list, so if he disagrees, we can take it to gd-general)

> I searched the archives for NAT and came up with 14 posts. Some say
> NAT is a problem, others say it's no problem especially when using

NAT is not a problem if you know what you're doing.  That's not meant=20
to be flippant or derogatory, but only to point out that A.) it's a=20
hairy problem to the uninitiated and B.) it's a solvable problem.

> They each get their address locally (192.168.1.100) and send that
> to the server in a packet it can understand. The server reads the
> packet and also notes the ip address of the received packet, so now
> the server has both the public and private address of a given
> client. It then sends each of the clients the other's address(es)
> and they try to contact each other.

Sounds about right.

> Is this correct so far? Does it work because the NAT assigned
> different internal port numbers to the outgoing requests so it uses
> that to route the incoming packets back to the requestor?

Yes, but you can't rely on this.  UDP is a connectionless protocol, so=20
in _theory_ (but rarely in practice, at least in the past 5 years or=20
so), the reverse port mapping can change on a per packet basis.  This=20
is described in a bit more detail in my article on multiplayer=20
programming you can find at bookofhook.com

> In a slide near the end they say they do some port guessing based
> upon common patterns. Why would they need this if a third party
> server is used?

What they're trying to do is allow two players to connect to each=20
other _without opening up any ports_.  At least, that's my=20
understanding.  This avoids the entire "explaining to users how NAT=20
works and why they can't host a server" problem.

> Also, Brian Hook mentions in one of his posts in the archive about
> using the lower 16 bits of the ip address as a unique identifier.
> Why would I need to do this?

To resolve clients behind a NAT.

> There is also a mention that you shouldn't hard code port numbers.
> Is there a recommended way to generate one?

Which port numbers?  For your server, you should hardcode them (so=20
that you can tell users what ports to open/forward) but you should=20
also allow them to be relocated in case there's a conflict.

> Finally, what if I am playing a game where two of us are behind a
> NAT on a LAN but connected to the same game on the internet. It's
> likely that I would recieve an address from the server of some
> other player's private address that would coincide with the address
> of my friend.=20

No, you'll receive the other person's _public_ address and port=20
mapping (ideally) that allows you to communicate with them directly. =20
At least, that's what I'm assuming they're trying to do.  If you=20
received 192.168.1.100, well, that's not too helpful since it'll just=20
route to your own internal network (on a router that uses that=20
mapping).

Brian

**End Brian Hook's Reply**
**Begin Second Post**

> This is precariously on the border of being OT and should probably be=20
> handled on gd-general, but I don't think it's flagrant (but it's Tom's =

> list, so if he disagrees, we can take it to gd-general)

I posted it here since there was discussion before on this list with no =
mention of OT at that time. Let me know if you want it moved to =
GD-General and I will do so immediately.

> What they're trying to do is allow two players to connect to each=20
> other _without opening up any ports_.  At least, that's my=20
> understanding.  This avoids the entire "explaining to users how NAT=20
> works and why they can't host a server" problem.

Couldn't they host a server as long as the third party matchmaking =
server game out thier public ip? Or is the rarely changing port number =
the problem here too? There isn't much difference between a client and a =
server once the third party matchmaking knows the correct ip and port =
number is there?

>=20
> > Also, Brian Hook mentions in one of his posts in the archive about
> > using the lower 16 bits of the ip address as a unique identifier.
> > Why would I need to do this?
>=20
> To resolve clients behind a NAT.
>=20

So this number would be used to identify players internally rather than =
ip/port, and when I want to send the packet I lookup the ip/port based =
upon this?
=20
> > Finally, what if I am playing a game where two of us are behind a
> > NAT on a LAN but connected to the same game on the internet. It's
> > likely that I would recieve an address from the server of some
> > other player's private address that would coincide with the address
> > of my friend.=20
>=20
> No, you'll receive the other person's _public_ address and port=20
> mapping (ideally) that allows you to communicate with them directly. =20
> At least, that's what I'm assuming they're trying to do.  If you=20
> received 192.168.1.100, well, that's not too helpful since it'll just=20
> route to your own internal network (on a router that uses that=20
> mapping).
>=20

Is this correct? So if I'm behind the same NAT as my friend, will the =
router detect the outgoing public ip address and port and reroute it =
back inside directly to them?

Brett

** End Second Post**

Re: [GD-General] Graphic Library and market share

[Sebastian U. <li...@in...>]

    We'll give that a try first then, before trying the switch to dx. 
Thanks for the advice!
    I also remember we had some problems with the handling of HWSURFACEs 
and back buffer (some strange things with the color channels changing 
when we switched between fullscreen and window mode), but due to our 
inexperience with SDL we aren't sure if it's our fault or SDL (we *do* 
know that there were some bugs with ARGB -> ARGB surface blitting, 
didn't find any reference to this solved on the web - will keep looking 
for answers :) ).
    So all this problems are pushing us to try other rendering 
library...  And as I said before, we don't want to restrict our target 
audience (by using "slow" SDL or "fast-hardware-demanding" DX).

brian sharon wrote:

> Switching to DirectX won't necessarily fix your alpha-blending 
> problems, as the crappy machines are also the least likely to support 
> hardware-accelerated 2D blits (I'm just assuming 2D here as you're 
> using SDL).  Of course you can switch to a 3D API and get blending 
> done by the hardware, but then you'll be requiring hardware 
> acceleration for a 2D game, which is probably not what you want to do :)
>
> I would guess that you're setting up your back buffer in video memory 
> and rendering your sprites there.  What kills you there is the need to 
> read rendered pixel values back off the video card so that the CPU can 
> do the alpha blend between source and destination.  Transferring data 
> back from the video card is slooooooow.
> I had the same problem with an SDL app a couple of years ago.  Here's 
> how I set things up to fix it:
>
> * render the entire frame to a buffer in system memory (with 
> alpha-blending enabled)
> * do one large screen-sized copy blit from system memory to the back 
> buffer on the video card
> * flip the back buffer to the front
>
> Switching to rendering in system memory provided a significant 
> performance boost for me.  I'd try that before you rewrite your app.
>
> --brian


-- 
///
Sebastián Uribe
Inmune Games
su...@in...
www.inmune.com.ar

Re: Spec costs was RE: [GD-General] The joy of type aliasing and C

[Brian H. <ho...@py...>]

> ISO/IEC 14882:2003 - Programming languages - C++ - $281.00
> INCITS/ISO/IEC 14882-2003 - Programming languages - C++ - $18.00

No idea, but I did find the 1998 one there (I have a copy -- they 
watermark every copy so that they don't get warezed, btw) and paid 
$18.00 for it.

> What is the difference between these two? They are both 2.35 MB and
> reading the descriptions didn't enlighten me that much...

Probably no difference at all, just a screwed up database.  Get the 
$18 one =3D)

> Then there's the 1997 C++ Public Review document on the web that I
> use for quick reference:
> http://anubis.dkuug.dk/jtc1/sc22/open/n2356/. How much did the
> final 1998 standard differ from this public review document? Does
> the actual draft contain more info? Are there other websites
> available?

That's probably good enough for basic stuff.  The differences between
draft and final versions tend to be fairly small.  And if worse comes
to worse, you can always post to comp.std.c++ and suffer through some
patronizing and condescension but eventually you might get a straight
answer =3D)

Brian

Re: Spec costs was RE: [GD-General] The joy of type aliasing and C

[Wesley H. <wes...@re...>]

Ok, can someone educate me on the various documentes available? I went to
http://webstore.ansi.org/ and searched for the C++ keyword and got the
following results:

ISO/IEC 14882:2003 - Programming languages - C++ - $281.00
INCITS/ISO/IEC 14882-2003 - Programming languages - C++ - $18.00

What is the difference between these two? They are both 2.35 MB and reading
the descriptions didn't enlighten me that much...

The 1998 version isn't shown, and the link you posted below results in an
error msg: "The product you requested is currently not available."

Then there's the 1997 C++ Public Review document on the web that I use for
quick reference: http://anubis.dkuug.dk/jtc1/sc22/open/n2356/. How much did
the final 1998 standard differ from this public review document? Does the
actual draft contain more info? Are there other websites available?

Thanks,
Wes




----- Original Message ----- 
From: "Neil Stewart" <ne...@r0...>
To: <gam...@li...>
Sent: Friday, December 26, 2003 5:56 PM
Subject: RE: Spec costs was RE: [GD-General] The joy of type aliasing and C


> > No, I misspoke, it's $273.  That is not a typo.
> >
> > http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%
> > 3A2003
>
> Ah, that's the new C++0x (now called C++03) standard, which was recently
> published. Most compilers are still catching up on the 1998 standard,
which
> they are still selling for $18:
>
>
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+148
> 82%2D1998
>
> - Neil.
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

Re: [GD-General] Graphic Library and market share

[brian s. <pud...@po...>]

Switching to DirectX won't necessarily fix your alpha-blending problems, 
as the crappy machines are also the least likely to support 
hardware-accelerated 2D blits (I'm just assuming 2D here as you're using 
SDL).  Of course you can switch to a 3D API and get blending done by the 
hardware, but then you'll be requiring hardware acceleration for a 2D 
game, which is probably not what you want to do :)

I would guess that you're setting up your back buffer in video memory 
and rendering your sprites there.  What kills you there is the need to 
read rendered pixel values back off the video card so that the CPU can 
do the alpha blend between source and destination.  Transferring data 
back from the video card is slooooooow. 

I had the same problem with an SDL app a couple of years ago.  Here's 
how I set things up to fix it:

* render the entire frame to a buffer in system memory (with 
alpha-blending enabled)
* do one large screen-sized copy blit from system memory to the back 
buffer on the video card
* flip the back buffer to the front

Switching to rendering in system memory provided a significant 
performance boost for me.  I'd try that before you rewrite your app.

--brian

Sebastian Uribe wrote:

> ###
> Note: Sorry if this appears twice, i first sent it with another email 
> address (not subscripted to the list) but it's still awaiting 
> moderator approval
> ###
>
> Hi,
>
>   We're making some small puzzle game for Win32 to be (hopefully) 
> distributed online. We're currently using SDL (as we had planned to 
> make it easily portable), but some problems with it are slowing down 
> our development (timer granularity and slow alpha blitting mostly).
>   So we're thinking in using DirectX for now, and later care about 
> other platforms. I wanted to get some idea about the installed base of 
> DirectX. I believe DX8.1 comes with Windows XP, and at least DX6 or 
> DX7 must come with W2K. We don't care a lot about W98 right now 
> (¿Should we?). Our programmers say DX8 will be easier to use tan DX7, 
> but I'm worried it will restrict our market share, as we're not 
> targeting hardcore gamers (with the latest in machine and OS).
>
>   ¿What's your experience with this? Any comment will be appreciated!
>
> PD: I believe OpenGL would probably be well suited also, but the main 
> programmer in this proyect feels more comfortable with DX.
>
>   Thanks
>