Iana - The Internet Assigned Numbers Authority (IANA) is a department of ICANN responsible for coordinating some of the key elements that keep the Internet running smoothly Iana provides a list of UDP (user datagram protocol)and TCP ports available in the Internet: Html formatted list http://www.iana.org/assignments/port-numbers Text file format (not from Iana) http://significantive.com/japanese/traffic/port-numbers.htm port 1494 was registered by John Richardson port 1604 was registered by Brandon Pederson Is port 1604 still being used by Citrix? Check this out: Carl Weber Also check this discussion on port 1604: The security department in my company have told me that I have a security risk on one of my XenApp5.0 servers on Windows Server 2003: "This information leak is using the legacy UDP Citrix browser functionality. This has since been replaced with a TCP-based mechanism for application enumeration that does not have this issue, but a default Citrix installation enables the legacy UDP enumeration functionality for backwards compatibility. You can disable the legacy functionality in the Citrix Access Management Console under Farm Properties. In the configuration page under "Farm Properties..., Presentation Server...., General, simply clear both check boxes in the "Respond to client broadcast messages" section at the top of the dialog box. This will disable the UDP 1604 responses from your Citrix servers." However clearing these checkboxes does not fix the problem. If I run netstat -an |find /i "1604" I see (I'm not sure what this means - that the port is open?): UDP 0.0.0.0:1604 : I asked for more information and they recommended I try a forum. Any help greatly appreciated! Answer: The Farm settings you reference determine if the servers will respond to the UDP broadcast requests, not whether the listener is created. If you want to remove the listener completely, under the Server Properties on each server in your farm, select ICA, Browser, and clear both check boxes here. This will remove the UDP listener completely. =========================================================================== So it appears that port 1604 has been deprecated by Citrix (to be verified) P.S.
Here is an outstanding explanation by Glenn Fiedler of TCP/IP and UDP (source: Gaffer on Games )
TCP/IP
TCP stands for “transmission control protocol” and IP stands for “internet protocol”. Together they form the backbone for almost everything you do online, from web browsing to IRC to email, its all built on top of TCP/IP.
If you have ever used a TCP socket, then you’ll know that it is a reliable connection based protocol. This simply means that you make a connection between two machines, then you send data between the two computers much like you are writing to a file on one side, and reading from a file on the other.
This connection is reliable and ordered, meaning that all data you send is guaranteed to arrive at the other side in the same order that you wrote it. Its also a stream of data, meaning that TCP takes care of splitting up your data into packets and sending those across the network for you.
Again, remember its just like writing to a file. So simple!
IP
The simplicity is in stark contrast to what actually goes on at the lower level “IP” protocol underneath TCP.
Here there is no concept of connection, instead packets are passed from one computer to the next. You can visualize this process like a hand-written note being passed from one person to the next across a crowded room, eventually reaching the person it is addressed to, but only after passing through many hands.
There is no guarantee that this note will actually reach the person it is addressed to. The sender just passes the note along and hopes for the best, never knowing whether or not the note was received, unless the other person decides to write back!
Of course, it is in reality a little bit more complicated than this, since of course no one computer knows the exact sequence of computers to pass the packet along to so that it reaches its destination quickly. Sometimes “IP” passes along multiple copies of the same packet, these packets make their way to the destination via different paths, so will most likely arrive at different times.
This is because the internet is designed to be self-organizing and self-repairing, able to route around connectivity problems. It’s actually quite cool if you think about what it isreally going on at the low level. You can read all about this in the classic book TCP/IP Illustrated.
UDP
Instead of treating communications between computers like writing to files, what if we want to send and receive packets directly?
We can do this using UDP. UDP stands for “user datagram protocol” and it is another protocol built on top of IP, just like TCP, but this time instead of adding lots of features and complexity it is just a very thin layer over IP.
With UDP we can send a packet to a destination IP address (eg. 112.140.20.10) and port (say 52423), and it will get passed from computer to computer until it arrives at the destination computer or is lost along the way.
On the receiver side, we just sit there listening on a specific port (eg. 52423) and when a packet arrives from any computer (remember there are no connections!), we get notified of the address and port of the computer that sent the packet, the size of the packet, and can read the packet data.
UDP is an unreliable protocol. In practice, most packets that are sent will get through, but you’ll usually have around 1-5% packet loss, and occasionally you’ll get periods where no packets get through at all (remember that there are lots of computers between you and your destination where things can go wrong…)
There is also no guarantee of ordering of packets. You could send 5 packets in order 1,2,3,4,5 and they could arrive completely out of order like 3,1,2,5,4. In practice, they will actually arrive in order almost all of the time, but again, you cannot rely on this!
Finally, although UDP doesn’t do much on top of IP, it does make one guarantee for you. If you send a packet, it will either arrive in whole at the destination, or not arrive at all. So if you send a 256 byte packet to another computer, that computer cannot receive just the first 100 bytes of the packet, it must get the full 256 bytes of data. This is pretty much the only guarantee you get with UDP, everything else is up to you!
TCP vs. UDP
We have a decision to make here, do we use TCP sockets or UDP sockets?
Lets look at the properties of each:
TCP:
- Connection based
- Guaranteed reliable and ordered
- Automatically breaks up your data into packets for you
- Makes sure it doesn’t send data too fast for the internet connection to handle (flow control)
- Easy to use, you just read and write data like its a file
UDP:
- No concept of connection, you have to code this yourself
- No guarantee of reliability or ordering of packets, they may arrive out of order, be duplicated, or not arrive at all!
- You have to manually break your data up into packets and send them
- You have to make sure you don’t send data too fast for your internet connection to handle
- If a packet is lost, you need to devise some way to detect this, and resend that data if necessary
The decision seems pretty clear then, TCP does everything we want and its super easy to use, while UDP is a huge pain in the ass and we have to code everything ourselves from scratch. So obviously we just use TCP right?
