About UDP port in p2p application

Question

I'm doing a small demo project of a DHT (p2p routing only, like Chord, Pastry, etc.), and I'm confused about the detail of transportation in a P2P network.

Assuming all peers communicate using UDP and the port is 10050, which is a fixed one, then consider two typical cases:

A may send a "JOIN" message to B.
Also, B may send a "JOIN" message (or other messages) to A according to the p2p nature.

In case 1, the destination port of the message must be 10050;

In case 2, the destination port of the message must be 10050;

I wonder what's the source port of the messages in both cases? If it's a random port decided by system calls, the DHT protocol stack need to process datagram on 10050 and the random port, is this the normal behavior in DHT based application (e.g., emule, bittorrent)?

the8472 · Accepted Answer · 2015-06-03T13:59:24.883

I wonder what's the source port of the messages in both cases? If it's a random port decided by system calls

You generally use a socket bound (POSIX bind()) to a specific local port. That local port will function both as a source port for outgoing messages and destination port for incoming messages at the same time. Note that for UDP you probably want to use the POSIX sendmsg() or sendto() calls and not send().

This is important for DHT protocols because other nodes infer which port you're listening on based on your source port and store that in their routing tables.

As for the specific port number, you can in principle use a fixed port number for your DHT, which means that other nodes don't have to infer the listening port because they know it's fixed.

But it is better to have some flexibility so port clashes can be avoided. So a node should generally be free to choose any port and then do all send and receive operations over that port.

Additionally, since IPv6 is becoming more common you will want to bind your socket to one specific address on your host, because v6 generally comes with multiple addresses per host and listening on multiple interfaces and sending messages from different IPs will make you appear unreliable to other DHT nodes (constantly changing IP addresses). I.e. do not bind to the any-local address (0.0.0.0 or ::0) if you can avoid it.

Figure out which local address is used for the default route and bind to that.

Thanks so much that everything is clear now! So the transport rule(assuming UDP) in DHT is using the same port for both send and receive operations while the port may be predefined or chosen dynamically, right? — realjin, Jun 03 '15 at 15:10
If nodes use a predefined listening port then the source port does not matter. If nodes can choose the port freely they either have to use send == receive port or have to explicitly encode their receive port as part of the DHT messages. — the8472, Jun 03 '15 at 15:42
I'm clear now, and I'll try to use the "send==receive port" approach in my demo as it allows port selection to avoid port clashes and is simple, thanks so much :] — realjin, Jun 04 '15 at 03:12

score -1 · Answer 2 · edited Feb 19 '16 at 23:52

Create a UDP socket and bind it to a port, then we still can use this socket to send message. UDP is symmetric, not like TCP.

The udp-socket need not be bound or connected; if it is not bound, udp-send-to binds it to a random local port.

(udp-send-to        udp-socket               
        hostname                 
        port-no              
        bstr                 
     [  start-pos                
        end-pos])       →       void
  udp-socket : udp?
  hostname : string?
  port-no : port-number?
  bstr : bytes?
  start-pos : exact-nonnegative-integer? = 0
  end-pos : exact-nonnegative-integer? = (bytes-length bstr)

Sends (subbytes bytes start-pos end-pos) as a datagram from the unconnected udp-socket to the socket at the remote machine hostname-address on the port port-no. The udp-socket need not be bound or connected; if it is not bound, udp-send-to binds it to a random local port. If the socket's outgoing datagram queue is too full to support the send, udp-send-to blocks until the datagram can be queued.

About UDP port in p2p application

2 Answers2