Thanks guys... but... if there''s only one way trafic, even with
a server, the server can''t communicate with the clients too. To
me the connection "client <--> client" and "server <-->
clients" are carried out the same way, I don''t see why one
works and the other fails... Any references for me to read up?
I must have missed the key point there.

you can make 2 way connections through a NAT no problem, but the connection has to originate from the client. when you make a connection from the client, you keep the connection open thus allowing the happy exchange of info in both directions. the server simply cannot initiate a connection to a client behind a NAT, because it doesn't know how to properly address the recipient. I'm not really sure of the whole TCP/IP mess beneath it but basically when you have an open connection, I believe that the server has the appropriate headers to attach to each packet so that the messge will filter properly through the NAT to the client.

the short of my understanding is that if you're doing network programming for a game you initiate your connections from the client and then leave them open for the duration of the game. if you need another connection at some point you can message down one of your open connections to the client and tell it to open another connection to you.

someone please correct me if i'm wrong.

-me

[edited by - Palidine on October 31, 2003 1:53:37 PM]

Edit: Read post above instead, it explains way better

Well, if a client (behind a firewall or whatever that stops connections from coming on) makes a connection to a server, then the firewall (or whatever) is aware that the data coming from the server is "return-traffic" and lets it through.
I'm getting a feeling that I'm not very good at explaining this, but maybe it gives you a slight idea of what I mean...

[edited by - Jolle on October 31, 2003 1:53:56 PM]

a good metaphor would be pipes. if the client builds a pipe from inside the firewall to somewhere outside the firewall, the firewall thinks of it as a good pipe since it originated from a "trusted entity" (i.e. someone inside). for as long as that pipe stands there, the firewall doesn't necessarily look at the data travelling through it (i believe that there are circumstances where it does, aka packet filtering...not really 100% sure through). the firewall otherwise regards all pipes originating from the outside world as "bad pipes" and blocks their construction. firewalls allow you to open up ports through which incoming connections can be made, NATs allow you the same options. The idea is that sometimes you want your computer to be able to host data (like a web server). by opening up a port you are letting the firewall know that all incoming pipes being constructed on, say, port 80 are fine, my application will handle the security of that port.

er...ok?

-me

[edited by - Palidine on October 31, 2003 2:00:27 PM]

Alright guys, thanks so much! I think I get the firewall idea.
Say for my scenario, there are three existin'' clients in the
chat session (C1, C2 and C3). Now new client C4 comes and join
the chat session, it first connects to the server. This is
possible because the server has opened up specific ports to
listen to all these connection events, so it goes through firewall.

But the C4 cannot send message directly to C1, C2 and C3
because they are behind firewall, and since all "incoming pipes
are bad", firewall rejects the connection originated from C4.
Same applies if either one of C1, C2 and C3 tries to connect to
C4. So this is why P2P will not work!! I got it!

OK now here''s another idea to solve this, what if I open up
port number N on all the clients? This way they are able to
communicate with each other right?

---

quote:

---

the server does not have to know about the chat
messages. It just takes care of the log in/out and other server
specific tasks.

---

"other server specific tasks" often includes ignore lists, dirty word filtering etc... Another reason to use a central server.

Peer 2 Peer can still work on 90% (or so) of the nat''s.
Here''s a popular workaround:
http://www.alumni.caltech.edu/~dank/peer-nat.html
It''s a bit messy to implement, but it actually works!

Some IRC clients have a feature called DCC chat (direct client-to-client) that allows sending messages without going through the server.

I suspect one of the main reasons why chat systems use a server is that it''s more efficient than p2p when there are many clients talking on the same channel. Each client only has to maintain connection to the server, not potentially hundreds of other clients. (And then you also just need to know the server''s [usually permanent] ip address to get in)

The problem with NAT''s is this (firewall issue aside, since they are two different things):

Suppose you have 4 clients all behind a NAT.

Client 1 with ip address 192.168.0.2
Client 2 with ip address 192.168.0.3
Client 3 with ip address 192.168.0.4
Client 4 with ip address 192.168.0.5

The internal ip address of the NAT is 192.168.0.1 and this is the default gateway for the clients.

The external ip address of the NAT is 123.234.45.90 (just a random ip address i made up)

Now suppose you have a client (Client 5) on another network whos not behind a NAT and has an ip address of 55.23.78.124 (again another made up ip)

Say Client 5 wants to send a message to Client 2. What IP address does Client 5 send the message to? Can''t send it to the 192.168.0.3 ip since its not a address thats routeable on the internet. If you send the packet to the external interface of the NAT (123.234.45.90), the NAT has no idea who the packet is for, theres 4 PC''s behind it and could be for any one of them.

Dedicated game servers can get around stuff like this by setting up a port forward on the NAT, so that any incomming data on a specific port gets forwarded to a specific internal IP address.

Hope this explains a bit more.

-=[ Megahertz ]=-

It's not just about message sending, it's about the keeping track of who's in the charroom. In a peer-to-peer environment, each pc will have session in RAM which keeps track of who's online. Each machine will keep broadcasting...

1) i m online
2) who else are online

So if in an environment of, say, 100 online persons, the network will be messed up.

Alternatively, you may have one pc hosting the session, it gets better, however it's virtually a host/client model, not a true peer-to-peer session. Even with a pc hosting the session, problem still exist when the host pc suddenly goes down, the session will end as a result.

So in an environment where sudden session end is not allowed, ie, MMOG, then a server/client model is the only solution.



[edited by - Hawkins8 on November 2, 2003 1:00:46 AM]