Difference between official and unofficial ports - udp

Here we can see list of some Well-known ports and Registered ports in TCP/UDP, When we look at the port number 2086 it is assigned for two different services, one is official for GNUnet and other is unofficial for WHM.
Exactly this port number duplication cause any issues when we install both services having same port number in our server?
What does it mean, these same port number is assigned, one for official and other for unofficial purpose ?

You have to distinguish between port numbers registered by IANA (Internet Assigned Number Authority) and commonly used port numbers. Port 2086 is only registered for GNUNet (see https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt), but is commonly used also for WebHostManager.
In practice you could use any ports you like inside an application, i.e. it is not forbidden to use registered ports for other purposes or use unregistered ports. But it might cause conflicts with other software using the same ports, so it is better to respect registered ports and register your own ports if your application is of some importance.
Apart from that, more and more applications just move to a protocol on top of HTTP, because this is the only port open on most firewalls :(

Related

Can DDS protocol be used to communicate between devices connected to different networks?How?

I am trying to implement a publish and subscribe hello world program for communication between 2 devices using eclipse cyclone DDS protocol, I am able to do it when devices are connected in the same network but when devices are in a different network there is no communication happening. As per my understanding, it's because of the default DDS domain but how do I change it?
I followed https://github.com/eclipse-cyclonedds/cyclonedds
Here there's a mention to make use of an XML file, but I am not understanding how to use it or where to use the file.
Any suggestion would be of much help, thank you!
Cyclone DDS looks at the value of the CYCLONEDDS_URI environment variable to find its configuration file. What you can do is make an XML file somewhere on your computer and put its path in that environment variable. E.g., on Linux:
export CYCLONEDDS_URI=/path/to/cdds.xml
or on Windows (“cmd”, I don’t know how to do it in powershell):
set "CYCLONEDDS_URI=c:/path/to/cdds.xml"
Windows is a bit tricky with the quotes, this seems to work fine. Then, when you start your application, Cyclone DDS will read that file and apply the settings in it. Of course you also need to know what to put in it.
For that, it is useful to know a few things about the networks you are using. In one network, it all works without any configuration because the UDP/IP multicast works semi-magically in a single network. If there are multiple networks, there is a router in between and those routers are often configured not to route multicast traffic.
That means you basically have two options:
Configure the routers to route multicast traffic between the networks (especially the 239.255.0.1 address used by default by DDS). If that works, you’re all set, no need to configure anything in Cyclone DDS.
Disable the use of multicast and instead list the hostnames/IP addresses of the machines you want to communicate with in the configuration file. You still need a router willing to route traffic from the one network to the other, but that is usually not a problem with unicast packets. (If for example you can ping it or login to it remotely, it’s fine.)
For (2), something like:
<CycloneDDS>
<Domain>
<General>
<AllowMulticast>false</AllowMulticast>
</General>
<Discovery>
<ParticipantIndex>auto</ParticipantIndex>
<Peers>
<Peer Address="ip-of-node-1" />
<Peer Address="ip-of-node-2" />
<Peer Address="ip-of-node-3" />
/Peers>
</Discovery>
</Domain>
</CycloneDDS>
should work (obviously with the ip-of-node-1 &c. replaced with the correct addresses/hostnames). Setting “AllowMulticast” to false simply disables all use of multicast. If multicast doesn’t work reliably with all nodes, assuming it works can give a broken system. So at this stage, it is definitely easier to just not use it.
The “ParticipantIndex” has to do with the UDP port numbers it uses. With multicast, multiple processes on a single machine can all use the same UDP port number for receiving the discovery packets, and so there is this agreed-upon port number for discovery that makes everything work without any configuration (port number 7400 for domain id 0). That in turn allows it to use random port numbers for receiving unicast traffic.
With unicast, however, each process needs to have its own unique port number, and that in turn means the other processes need to know to which port numbers to send the data to. Setting the “ParticipantIndex” to auto forces it use predictable port numbers so that the processes can find each other.

Approaches for having multiple applications receive data via port 80

I'm looking for suggestions about approaches to allow multiple applications to use port 80 for communication.
I know it's impossible, or at lease not sensible to have multiple applications to actually bind to port 80, however, I've seen appliances when there is a device that provides both a web interface (HTTP) and RTSP with RTP using port 80.
I have two ideas on how this is achieved:
Are those custom made apps that implement all the functions?
For example the same binary is used for a web server and a RTSP server. That seems kind of limiting due to the fact that you would have to do sever modifications to already developed apps if you want, for example, Apache and openSSH both on port 80.
Are there a "port 80 multiplexers" sort of a pattern?
For example, a parser application that listens to port 80 and depending on the header of the received package, passes the package to the required application.
Found some related references, will give them a try.
https://bbs.archlinux.org/viewtopic.php?id=99457
http://www.rutschle.net/tech/sslh.shtml
I really don't think this is possible in a standard way: port number is actually the one that allows multiplexing among different applications in TCP and UDP protocols. More generic, TSAP, Transport Service Access Point allows multiplexing at the transport layer. TSAP is the port in protocols such as TCP, UDP, or SCTP.
One reason you may want two applications listening on the same port is that a second application can monitor or process in some other way the messages received, and eventually processed, by the first one. In this case, using pcap library other applications could read messages received by the main application that will probably response those messages.
Netfilter can also be useful, http://www.netfilter.org/
However, if you intend two applications to respond messages that arrive to the same port, that would be tricky and would have dependency on each application.
In this response I'm assuming you are thinking of applications listening to the same port at the same IP address. Something different is working with multihost servers where two applications could listen to same port number in different IP addresses.

Configuring address and ports for JGroups

When using JGroups, with a component such as Infinispan, it is possible to configure the ports and addresses that JGroups will use.
http://www.jgroups.org/manual/html/user-advanced.html
For example:
<UDP
mcast_addr="${jgroups.udp.mcast_addr:228.6.7.8}"
mcast_port="${jgroups.udp.mcast_port:46655}"
...
But here is what is confusing me. How can all members of the cluster all use the same port, addr?
I would have thought each member would have its own port and have to know the ports (and addresses) of the other members it needs to talk to?
Thanks
Multicast is a special address that can be used by multiple nodes to send/received data - think of it like 127.0.0.1, which is also available on most boxes with network installed.

Should I assign my WCF P2P app a Port?

I'm building a WCF P2P service using the PNRP functionality.
I see that I can assign a port to the Bindings... but most of the examples do not.
Is there a reason I should or shouldn't give it a port?
If you don't assign a port, WCF will choose a random available port automatically. The local port information is broadcast to peers as part of the PNRP process, so setting a local port explicitly is more to make your application predictable than anything else.
I usually set my ports explicitly so that I can document them to my customers. This is especially important when a customer uses a 3rd party firewall that I can't easily configure in code. If your app assigns a random port, they won't know what port to unblock in their firewall software.

Advantages of uPNP/IGD over SOCKS?

I'm curious why is it more pervasive. Does it has a better API?
I remember long ago when i first learned about NAT (i used it for sharing a dialup 14.4kbps modem), i thought that someday every home would have a router with NAT included, but it would "obviously" need also a SOCKS process to be able to open listening ports. When broadband started appearing, it was nice to see NAT as a common feature, and I supposed that SOCKS would be an extra, and slowly become more and more common... but nothing! i had to manually forward ports. then appeared that uPNP, but very few 'serious' applications support it, mostly P2P sharing, games, and some IM.
I still haven't seen any home router to include SOCKS (apart from Linux-based firmware upgrades, of course). does anybody know why??
edit:
as Vartec noted, UPnP is a zeroconf and service discovery, not proxy service. now i know that what i'm referring to is IGD protocol, the NAT traversal service present in home routers, and discovered via UPnP. so, my question would more properly be "Why IGD/UPnP instead of SOCKS?"
SOCKS has limitations compared to UPnP. Generally SOCKS requires configuration on each client and isn't transparent to applications (system-wide socket SOCKSification isn't installed/enabled by default on Windows), while NAT even without UPnP mostly works transparently and without any additional client configuration for outgoing TCP sockets and outgoing UDP.
NAT with UPnP also supports server TCP sockets better than SOCKS: SOCKS can only accept a single connection with its BIND request, which is okay for receiving a single TCP connection in a protocol like FTP, but useless for running a server that needs to accept many connections from many clients. SOCKS 4 also had a 2 minute timeout on the BIND request, but a server generally cannot know when the next client will try to connect.
Low-level TCP settings (eg. TCP Nagle, traffic class) also don't work across the SOCKS proxy, but they work through a NAT.
As far as I know, UPnP is zeroconf discovery type of protocol for devices in local networks, while SOCKS is tunnel-proxy server. They are completely different, actually I don't see anything, that they would have in common.
these are two different things, socks is a protocol that allows you to route tcp and udp (socks v5) through a proxy server and it's for outgoing connections, routers dont have anything to do with this (except they are acting as a proxy too)
the IGD of upnp is an 'api' that allows you to tell your router that you want to open a port and foward it to a computer, this is for incoming connections.. my linksys came with upnp enabled by default and one app i know to use this is msn messenger (maybe only for file transfers)