UDP protocal DATA FORMAT?

[altenbach]

---

@Joseph_Loo wrote:

Is the computer and the device in the same subnet? If it isn't, then UDP is not an option.

---

What do you mean? UDP TCP/IP (TCP, UDP, etc) is worldwide routable as long as both have public addresses.

[MrConfused]

Hey altenbach,

Please bear with me because the information is all on a PDF I left at home.

As for a typical recieved string, that is what I am trying to figure out.  I do not have the gas analyzer yet, so all I can currently rely on are the examples presented in the manual under the LAN connection section.

[Joseph_Loo]

TCP is routable. UDP is not. There is a difference.

[altenbach]

---

@Joseph_Loo wrote:

TCP is routable. UDP is not. There is a difference.

---

Wrong! UDP is fully routable. How else can you stream music or chat across the world. Most of these protocols are UDP based.

 For example "chrome remote desktop" uses UDP exclusively.

[Joseph_Loo]

So what are you going to do when you loose a packet.

[altenbach]

---

@Joseph_Loo wrote:

So what are you going to do when you loose a packet.

---

Nothing!

UDP is not connection based, so packet loss will just cause missing packets. No big deal when e.g. streaming a video or internet radio, because a retransmission request of a missing packet as in TCP would come too late anyway. These programs are designed to intelligently deal with packet loss and gloss over it.

UDP is great due to the inherent simplicity. There are plenty of scenarios where it is completely sufficient. It is used for many things such as DNS queries and NTP time sync. Establishing a TCP connection ( establishing threeway handshake, data, acks, mutually breaking down the connection, etc.) is a lot of work just do do a DNS lookup. If we don't get a response, the computer just asks again or contacts a backup server.

(Of course you can do a psuedo connection using UDP, e.g. by numbering packets and communicating back and forth until everything is in place, but since TCP already has all this built into the protocol, you would use TCP if reliability is required.

[Joseph_Loo]

So if you are assuming an answer to come back, you may never receive it. You will not know wheteher the error occurred in the transmission of your packet or the receiving of the packet. As a result, data can be completely missed. You are right, it can be routed however if you want to maintain good communication with a device without writing a bunch or retransmission and hand shake, your data can be missed. In addition, if you go and check the firewalls for a lot of corporate setups, UDP is blocked, thus only if you transmit the first udp packet there is a chance of receiving the signal. Even then, they may set up rules that block it completely thus non-routable.

[altenbach]

You said UDP was not routable and I said it was.

---

@Joseph_Loo wrote:

So if you are assuming an answer to come back, you may never receive it. You will not know wheteher the error occurred in the transmission of your packet or the receiving of the packet. As a result, data can be completely missed. 

---

Discussing the advantages and disadvantages of UDP is an entire different discussion. TCP and UDP are both fully implemented in LabVIEW for the obvious reason that both offer advantages depending on the scenario. If your instrument sends a UDP packet every 5 seconds to indicate a tank temperature and you don't hear from it for a minute, you can assume something is wrong even without mainaining a constant two-way session. After the instrument is rebooted, the packets will arrive again and no further actions are needed. If you would use TCP, a new session would need to be established from scratch. UDP also allows multicast so a single message is addressed to a group of listeners while TCP is always strictly 1:1. Often missed packets are acceptable.

---

@Joseph_Loo wrote:

In addition, if you go and check the firewalls for a lot of corporate setups, UDP is blocked, thus only if you transmit the first udp packet there is a chance of receiving the signal. Even then, they may set up rules that block it completely thus non-routable.

---

Most firewalls and NAT routers allow most UDP traffic, especially if it is return traffic from an outgoing UDP request. They simply maintain an entry in the session table. For example if a random DNS return packet arrives at some random port, the firewall will block it, but if there was an earlier outgoing request coming from that same random source port to the DNS server, the firewall will allow it (and if NAT is involved, will even rewrite the packet header to be consistent with the private network).

[Joseph_Loo]

Discussing the advantages and disadvantages of UDP is an entire different discussion. TCP and UDP are both fully implemented in LabVIEW for the obvious reason that both offer advantages depending on the scenario. If your instrument sends a UDP packet every 5 seconds to indicate a tank temperature and you don't hear from it for a minute, you can assume something is wrong even without mainaining a constant two-way session. After the instrument is rebooted, the packets will arrive again and no further actions are needed. If you would use TCP, a new session would need to be established from scratch. UDP also allows multicast so a single message is addressed to a group of listeners while TCP is always strictly 1:1. Often missed packets are acceptable.

---

You are missing the point. UDP does not guarantee any transmission of data. If you have a critical data requirement for data UDP rquires a lot of overhead.

As for mulitcast, it best works within a subnet. Most routers will block a multi-cast from going to another subnet.

@Joseph_Loo wrote:

In addition, if you go and check the firewalls for a lot of corporate setups, UDP is blocked, thus only if you transmit the first udp packet there is a chance of receiving the signal. Even then, they may set up rules that block it completely thus non-routable.

---

Most firewalls and NAT routers allow most UDP traffic, especially if it is return traffic from an outgoing UDP request. They simply maintain an entry in the session table. For example if a random DNS return packet arrives at some random port, the firewall will block it, but if there was an earlier outgoing request coming from that same random source port to the DNS server, the firewall will allow it (and if NAT is involved, will even rewrite the packet header to be consistent with the private network).

_____________________________________________________________________________________________

You are looking only at systems you have control over. In most case, corporate policies will not allow the input of UDP unless there is an exception, which is probably very difficult in getting.

[Joseph_Loo]

Discussing the advantages and disadvantages of UDP is an entire different discussion. TCP and UDP are both fully implemented in LabVIEW for the obvious reason that both offer advantages depending on the scenario. If your instrument sends a UDP packet every 5 seconds to indicate a tank temperature and you don't hear from it for a minute, you can assume something is wrong even without mainaining a constant two-way session. After the instrument is rebooted, the packets will arrive again and no further actions are needed. If you would use TCP, a new session would need to be established from scratch. UDP also allows multicast so a single message is addressed to a group of listeners while TCP is always strictly 1:1. Often missed packets are acceptable.

---

You are missing the point. UDP does not guarantee any transmission of data. If you have a critical data requirement for data UDP rquires a lot of overhead.

As for mulitcast, it best works within a subnet. Most routers will block a multi-cast from going to another subnet.

@Joseph_Loo wrote:

In addition, if you go and check the firewalls for a lot of corporate setups, UDP is blocked, thus only if you transmit the first udp packet there is a chance of receiving the signal. Even then, they may set up rules that block it completely thus non-routable.

---

Most firewalls and NAT routers allow most UDP traffic, especially if it is return traffic from an outgoing UDP request. They simply maintain an entry in the session table. For example if a random DNS return packet arrives at some random port, the firewall will block it, but if there was an earlier outgoing request coming from that same random source port to the DNS server, the firewall will allow it (and if NAT is involved, will even rewrite the packet header to be consistent with the private network).

_____________________________________________________________________________________________

You are looking only at systems you have control over. In most case, corporate policies will not allow the input of UDP unless there is an exception, which is probably very difficult in getting.

[altenbach]

---

@Joseph_Loo wrote:
You are missing the point.

---

What point? The OP has a device the requires communication via UDP so the choice of protocol is not even an option.

---

@Joseph_Loo wrote:
UDP does not guarantee any transmission of data. If you have a critical data requirement for data UDP rquires a lot of overhead.

---

TCP does not guarantee anything either. If the network is down, nothing goes. TCP just ensures that both sides are aware of the fact the the connection is not possible (e.g. if no ACKs are coming back). If you have critical data requirements, you don't use UDP if you have a choice.

The take-home message is that anything traveling over the IP protocol (TCP, UDP, ICMP, etc.) is fully routable. This can be overwritten by firewall policies, but that does not impact inherent routability (which you questioned).

IPv6 is starting to appear too, so things will get a bit more interesting in the future. 😄