Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
UDP and TCP are both used on top of IP which rests on Ethernet. How does one know which is needed? They both ultimately send and recieve data in packets.
I have no specific answer, but I use an 'easy networking' program called PC-Mac-Net-fileshare to network my computers of differing platforms.
It has a diagnostics window. If all goes well on startup, each computer displays 'TCP connection ok'. The 'auto-discovery' routine worked this time.
Sometimes it does not recognize the connection. Then I must try a few things. It has a button called 'TCP test' and a button called 'UDP test'. I click one. I click the other.
The TCP test can fail, but the UDP test is 'successful'. This makes me think the UDP protocol is less stringent, in regard to opening communications. However it is TCP which we see more often listed as a preferred protocol.
Anyway even if UDP connects, nevertheless that's just one step up the ladder. I still have to play with settings, in hopes I can get the message to say 'TCP connection ok'. I may need to choose 'set manually', type in the exact IP address, try another diagnostic, etc.
To give a simple example. UDP is fast, because it sends packets without confirmation on the transport layer. But you don't need the TCP acknowledge mechanism, if you have already a request/response scheme on the application layer. MODBUS over ethernet uses UDP for this reason.
Files or HTML data are better sent through TCP protocol.
UDP and TCP are both used on top of IP which rests on Ethernet. How does one know which is needed? They both ultimately send and recieve data in packets.
so if I design an embedded device (made using microchip PIC) which shall sit in a LAN and I want to be able to communicate with it to find what value it measures from switches and temperature sensors and then send it to my PC, will I use TCP or UDP? It seems that since TCP makes sure that data does get to the other side, it is most suitable for such a task.
However I advice you to use UDP since you will be sending small packages and you do not need to deal with establishing a connection. UDP produces far less traffic on the network since it does not need to check if the package is actually arrived at its destination.
Very few measurement applications send data in only one direction without any requests or responses in the other direction. I seems to me that you didn't yet start to think seriously about your application requirements.
For measurement data that represent a present state rather than an ordered sequence, UDP is the natural solution.
But the decision is arbitrary to some extent. So if you come to the conclusion that TCP is preferable, simply implement it and see how it goes.
so if I design an embedded device (made using microchip PIC) which shall sit in a LAN and I want to be able to communicate with it to find what value it measures from switches and temperature sensors and then send it to my PC, will I use TCP or UDP? It seems that since TCP makes sure that data does get to the other side, it is most suitable for such a task.
However I advice you to use UDP since you will be sending small packages and you do not need to deal with establishing a connection. UDP produces far less traffic on the network since it does not need to check if the package is actually arrived at its destination.
Regardless of what the other poster suggests it boils down to what are your requirements.
If the device needs to respond to queries from the LAN and you are using UDP you may end up timeouts if the UDP packet doesn't arrive in either direction. The PC application layer will have to support dealing with missing replies and resending the requesting UDP packets. Using TCP/IP on the other hand would allow you to just use a standard TCP/IP stack. UDP is really good for streaming data as that type of transfer typically has some sort of method of dealing with dropped data or dropped data can be effectively ignored e.g. video and audio. It's not so good for using as a control interface.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
