In my peer to peer application, should I use multiple ports?

Question

I am building a simple peer to peer application where about 8 participants all connect to each other (n*n). I will be using UDP with a reliability and ordering protocol layered on top. Each peer will be broadcasting a few KB of data per second.

It occurred to me that there are two ways of configuring the ports on each peer:

1. Each peer takes one port and all messages are received via that
2. Each peer takes a port for each other peer, and only communicates with a peer using its corresponding port

What are the advantages and disadvantages of each approach?

Answer 1

Creating only one port to communicate with each peers is the best option. You create only one socket and use only one port to send/receive data with as many peers as you want. You can distinguish received data by seeing source address of each packet. This way has Less complicated code and is more resource efficient.

Creating multiple port has absolutely no advantage. It will complicate your code and will use much more resource with no benefit. Resource consumption will grow with more peers.

Answer 2

I have never done anything with this model of application, but here are my few thoughts.

1 big thing to consider will be whether any firewalls are in place between the peers. If so, a hole will need to be punched through for each listening port. This can be done either once (eg. router port-forward rule) or dynamically (UPnP, etc), but you may not be able to count on automatic full-cone NAT to do this for you. If you are expecting any firewalls between your peers, I would recommend using a single port for ease of programming on your part and identify your peers strictly by their remote address or some other in-protocol identifier.

Using a single port per user will make identifying communication much simpler, but if you expect your number of participants to grow by n(n-1)/2. If you never expect more than a small number (eg. 20), port per peer will work decently well without much effort.

Another option for you (possibly) may be using multicast. If all of your peers are on the same broadcast domain, this will reduce bus contention and may make your coding somewhat cleaner as well.

Hope this helps. I apologize if this isn't what you're looking for. Good luck!

Answer 3

Each peer takes one port and all messages are received via that

If each peer can get the source IP/source port of the incoming datagram (and I bet it can), this is enough to differentiate the peers.

Each peer takes a port for each other peer, and only communicates with a peer using its corresponding port

See above, and most importantly this contradict your base idea of broadcasting in the first place. It just add a level of complexity (and is probably not very scalable, even if for now you envision just 8 peers).

In your base requirement I think you may have a dilemma between:

• broadcast everything to everyone,
• but still you want a peer to be able to "only communicates with a peer", which is inherently unicast.

This raises some problems, as you already realized by asking the question.

I see 2 other problems:

• Scalability-wise, the broadcast everything approach whereas you sometime actually need unicast is going to put some useless load on the network. This is not pretty.
• The broadcast approach dictates UDP, but still you want reliable data transfer, so as you stated you'll have to add a "reliability and ordering protocol layered on top". This (not so easy) work would not be needed if only we could use TCP.

There is a third approach:

• use broadcast UDP for each peer to announce itself on the network, so that other peers can...
• ...discover it and then establish a unicast TCP connection with this peer. No more reliability and ordering problems + reduced network load.

This approach is used in SSDP (Simple Service Discovery Protocol), part of UPnP. I do not suggest you use SSDP, it's probably bloated for what you want to do, you said you wanted something simple.

All in all, you first have to resolve your dilemma: decide and differentiate the data that really need to be broadcasted vs the unicast part. YMMV.

PS: with broadcast UDP also comes the problem that though OK on a LAN, this will not pass a router unless you use multicast routing. But that's another story.