How to talk to peers over the internet?

[Rotsey]

Hi,

I am writing a game that I want to net enable.

So I want to be able to connect to peers over the internet. I will
be sending very small packets of data.

What is the best way to do this?

Do I need a middle man server?

Can someone outline how to do it please?

rotsey

 

[John Timney \(MVP\)]

I would probably start by lookign at creating some form of UDP server and
listeners, though its not my area of expertise related to gaming.

http://www.codeproject.com/vb/net/TinyUDP.asp

UDP is a very lightweight comms approach so it might be the right approach
for you.

Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog

 

[Rotsey]

Ok John thanks

One thing, I was hoping for a solution that would not mean I have
to create a server app as i do not have access to a server. So
I would have to pay for a web host.

Is there a solution that is already up like peer to peer graph,
but that requires softqre to be installed on each peer which
and setup issues I think as well??

 

[Claire]

Hi rotsey,
The reason communications packages usually need a server is because it may
be the only way for users of that application to broadcast their presence to
other users..
Another reason is because it's not easy to traverse inwardly through routers
to someone's pc from the internet.
I believe that similar problems are solved by using nodal networks like bit
torrent, but I think there always has to be a known server/node running to
seed the network.

If you know the IP addresses of your peers and can enter those into your
communications application directly, you dont need a server.
All you need, as john says, is UDP listeners running and passing very small
packets. You yourself would have to design the chat protocol.

 

[Peter Duniho]

One thing, I was hoping for a solution that would not mean I have
to create a server app as i do not have access to a server. So
I would have to pay for a web host.

Is there a solution that is already up like peer to peer graph,
but that requires softqre to be installed on each peer which
and setup issues I think as well??

As Claire says, typically for best results you need an intermediate server
for match-making and to address the question of getting through NAT
routers (and some proxies even). On the latter, there's a technique
called "port tunneling" that takes advantage of the client of the NAT
router having already made communications on a given port to _some_ target
causing the NAT router to automatically forward traffic using that port
coming _from_ any target.

The server doesn't need to be able to handle a lot of traffic; the idea is
that the peer-to-peer communication is where the bulk of the data transfer
happens. The server is used for "introducing" one peer to the other.

You can also as an alternative use UPnP (Universal Plug-and-Play) as a
technique for handling some NAT router issues. Both port tunneling and
UPnP are _not_ universally supported. For any peer-to-peer application,
there will always be some users who need to deal with their own
configuration (typically this means configuring their NAT router to
forward traffic on a particular port to the given client PC).

Of course, none of that actually addresses the chat protocol. The above
are issues you have to deal with when doing any peer-to-peer networking.
As far as the suggestion that you use UDP goes, IMHO that's the right way
to go for things like streaming audio, but not so much for simple text
chat. It's not completely clear which you're talking about; if the latter
I would use TCP instead.

Keep in mind that with UDP you will have additional issues to deal with
that don't exist with TCP. UDP isn't "reliable", which means not only is
it possible datagrams you send simply will not arrive at the other end,
they may arrive but in a different order from which they were sent, or
they may arrive multiple times, or some combination of the two.

If you are willing to deal with those issues, UDP has the advantage that
it won't waste bandwidth trying to send data that is effectively out of
date. You decide what sort of latency you want in your chat protocol,
retain UDP datagrams that need to be reordered with data received so far
up to that length of time, and use whatever data you have, whether
complete or not, in order to play whatever audio you do have data for.

For audio, that's fine...you can leave out some data and the audio can
still be intelligible. But for text, you're going to want the
communications to be reliable anyway, and doing that with UDP is basically
just reinventing the wheel. Use TCP instead and then you don't have to
worry about it.

Pete

 

[Rotsey]

Thanks for replies guys.

I am actually only going to be sending integer values for the game.
And no more than a handful at a time. So very small amounts of data.

Would UDP be ok for this when it is fairly critical for that data to arrive
promptly and not duplicated. Although I could setup some validation
of the data so that I only consume one copy of the data sent. The game
will allow me that.

Pete, is port tunneling the same thing as "Hole punching"?
Is this easy to do for a first timer?

 

[Peter Duniho]

[...]
Would UDP be ok for this when it is fairly critical for that data to
arrive
promptly and not duplicated.

UDP does have the advantage that there's no built-in delay mechanism. TCP
uses the Nagel algorithm, which delays some transmissions for a very short
period of time, in case additional data is sent that can be combined with
the previously sent data...this is more efficient, but of course causes
some data to be sent later than it otherwise could have been.

Keep in mind that even though UDP in theory can result in more timely
delivery at least some of the time, in practice you may not realize the
benefit. It all depends on the network traffic, and things like whether
coalescing TCP traffic improves communication efficiency enough to reduce
lost IP datagrams forcing data to be resent.

IMHO, if you have a need for reliable delivery, you should just use TCP.
Don't switch to UDP unless you find that you have some serious problems
with the timeliness of the data, and even then don't expect switching to
UDP to be a panacea.

If you don't have a need for reliable delivery, and can easily implement
whatever minimal validation you do need, then UDP might be a good choice.

[...]
Pete, is port tunneling the same thing as "Hole punching"?

I have heard both terms used for the same thing, yes.

Is this easy to do for a first timer?

The basic idea is easy. Two different client contact a common server
reachable by both. The common server reports each client's actual network
address information to the other, and the clients then use that
information to attempt to contact each other directly.

Getting it to work in practice is tricky, mainly because there's no
specification requiring NAT routers to support it. So the first step in
testing an implementation is somehow making sure you're using a NAT router
that will behave in a way for port tunneling to work.

There was a recent article that I saw on the web six or twelve months ago
on the topic that was pretty detailed. I'm sorry I don't have the URL
handy, but a Google search may turn up something for you.

Personally, I'm not sure I would bother with it. It will only work with
some NAT routers, it does have the requirement of a public server your
peers can all reach, and you will be better off supporting something like
UPnP (not 100% available, but getting pretty close these days) and being
prepared to offer at least some minimal guidance to customers for
configuration of their routers to support your program.

Pete

 

[Rotsey]

ok thanks Pete again

[...]
Would UDP be ok for this when it is fairly critical for that data to
arrive
promptly and not duplicated.

UDP does have the advantage that there's no built-in delay mechanism. TCP
uses the Nagel algorithm, which delays some transmissions for a very short
period of time, in case additional data is sent that can be combined with
the previously sent data...this is more efficient, but of course causes
some data to be sent later than it otherwise could have been.

Keep in mind that even though UDP in theory can result in more timely
delivery at least some of the time, in practice you may not realize the
benefit. It all depends on the network traffic, and things like whether
coalescing TCP traffic improves communication efficiency enough to reduce
lost IP datagrams forcing data to be resent.

IMHO, if you have a need for reliable delivery, you should just use TCP.
Don't switch to UDP unless you find that you have some serious problems
with the timeliness of the data, and even then don't expect switching to
UDP to be a panacea.

If you don't have a need for reliable delivery, and can easily implement
whatever minimal validation you do need, then UDP might be a good choice.

[...]
Pete, is port tunneling the same thing as "Hole punching"?

I have heard both terms used for the same thing, yes.

Is this easy to do for a first timer?

The basic idea is easy. Two different client contact a common server
reachable by both. The common server reports each client's actual network
address information to the other, and the clients then use that
information to attempt to contact each other directly.

Getting it to work in practice is tricky, mainly because there's no
specification requiring NAT routers to support it. So the first step in
testing an implementation is somehow making sure you're using a NAT router
that will behave in a way for port tunneling to work.

There was a recent article that I saw on the web six or twelve months ago
on the topic that was pretty detailed. I'm sorry I don't have the URL
handy, but a Google search may turn up something for you.

Personally, I'm not sure I would bother with it. It will only work with
some NAT routers, it does have the requirement of a public server your
peers can all reach, and you will be better off supporting something like
UPnP (not 100% available, but getting pretty close these days) and being
prepared to offer at least some minimal guidance to customers for
configuration of their routers to support your program.

Pete