I'm working on a project of client/server form. In the the project I need to check both TCP and UDP flow if they are finished or not.
Since UDP has no FIN bit,is there a simple way to detect whether a UDP flow is completed or not?
The easiest way to detect the end of UDP is add some extro information in UDP packets. For example, we can add a FIN flag in the final packet.
The better way is to add a header part in UDP packets, so that you can do lots of things like controling the end of UDP flows or limiting the speed. That is how reliable UDP works.
Related
I am super new to the networking world, so I have a QTcpserver that's currently working with the newConnection signal, but I was wondering if I could use QUdpSocket with a QTcpServer ? It's this possible at all ?
TCP is a connection oriented stream over an IP network. It guarantees
that all sent packets will reach the destination in the correct order.
This imply the use of acknowledgement packets sent back to the sender,
and automatic retransmission, causing additional delays and a general
less efficient transmission than UDP.
UDP is a connection-less protocol. Communication is datagram oriented.
The integrity is guaranteed only on the single datagram. Datagrams
reach destination and can arrive out of order or don't arrive at all.
It is more efficient than TCP because it uses non ACK. It's generally
used for real time communication, where a little percentage of packet
loss rate is preferable to the overhead of a TCP connection.
StackOverFlow
So the simple Answer is No , You can't ,because tcp and udp are 2 different protocols .
I want to develop a program in c using pjsip for peer to peer file transfer. As pjsip uses ice and in ICE UDP is used, so do I need to handle the packet delivery assurance.
And as I would be sending the file by breaking it into several parts and them re assemble all the parts at the receiver's end, so do I have to maintain the sequence of the packets or can i assume that packets are delivered in the correct sequence??
With UDP you can neither assume that packets are delivered in order nor that they are delivered exactly once nor that they are delivered at all! So you need to come up with a protocol that does a lot of things which normally TCP would take care of. It has to reassemble the original data stream and handle the things I listed above.
Additionally, with UDP you can have the problem that you cause congestion. TCP can avoid that with its congestion avoidance algorithms, with UDP you can easily send packets too fast causing them to drop at the overloaded router.
All these are non trivial problems to solve so I suggest you read up on the topic. I'd start with a good book about TCP.
It seems that a UDP packet can be sent without a payload.
The only thing I can think of that doesn't need a payload is for NAT hole punching.
What else could this be used for?
This relates to my previous question Under Linux, can recv ever return 0 on UDP?
I suppose more to the point is that if it's been specified as part of some standard, then it's been thought to be useful somewhere right?
Anything! The UDP packet isn't empty -- it comes with the sender's identity. Therefore, such a packet could be used as a primitive kind of signal: maybe a hello, a goodbye, or a keep-alive.
With interfaces like sendmsg, an empty packet might be used in order to send auxiliary data, like a cmsg structure (which can be used for things like transferring file descriptors between two processes on Linux).
EDIT: One more use: NAT traversal algorithms such as STUN or UDP hole punching.
To answer the question of "why would a protocol do this": the old Daytime protocol just uses the arrival of a UDP packet to send back a reply packet. Similarly, it replies with time value as soon as a TCP connection happens regardless of any actual data that the TCP connection contains.
a UDP packet without payload may be sent to detect if a UDP port is closed. if closed, an ICMP-unreach is replied.
Is it doable to listen a device with 2 different filters and capture packets? For example i start listening a device with a filter and dumping the packets to a pcap file, after 15min can i start another listen on the same device with different filter and dump the packets to another pcap file without stopping the old one?
Does pcap_open or pcap_next_ex block the incoming packets? What i mean if a packet arrives while listening from two different threads one of them will get the packet and control it for filter can the other thread access the packet?
I hope im clear sorry for bad english.
can i start another listen on the same device with different filter and dump the packets to another pcap > file without stopping the old one?
Yes. Albeit, you'd better start that listener in a different thread/process to process it.
Does pcap_open or pcap_next_ex block the incoming packets?
It does not. It drops the packets to your pcap listener if one part (you or the OS) can't keep up with the incoming packets.
pcap will also duplicate the packets(speaking at least of the *nix pcap, assuming winpcap works the same) so if you have several pcap listners, filtering for the same packets , they will all get a copy.
For each open device handle you get, you have a seperate filter, and packet buffer.
say handle 'A' and handle 'B'
now lets say both handles are on the same network device.
Now lets say that the network device gets 4 packets.
each packet gets to the hardware driver, then to winpcap.
at that point winpcap applys each handles filter one at a time.
if a match is made, the packet will be copied to that handles packet buffer.
after all handles have been processed, the packet is handed off to the OS.
Does pcap_open or pcap_next_ex block the incoming packets? No.
The fact is that the operating system, will most likely see the packet before your application will process it.
I may be wrong but I don't think winpcap has any standard method for blocking a packet.
Let's say I am trying to send data using udp socket. If the data is big then I think the data is going to be divided into several packets and sent to the destination.
At the destination, if there is more than one incoming packets then how to I combined those separated packets into the original packet? Do I need to have a data structure that save all the incoming udp based on the sender ? Thanks in advance..
If you are simply sending the data in one datagram, using a single send() call, then the fragmentation and reassembly will be done for you, by the transport layer. All you need to do is supply a large enough buffer to recv(), and if all the fragments have arrived, then they will be reassembled and presented to you as a single datagram.
Basically, this is the service that UDP provides you (where a "datagram" is a single block of data sent by a single send() call):
The datagram may not arrive at all;
The datagram may arrive out-of-order with respect to other datagrams;
The datagram may arrive more than once;
If the datagram does arrive, it will be complete and correct1.
However, if you are performing the division of the data into several UDP datagrams yourself, at the application layer, then you will of course be responsible for reassembling it too.
1. Correct with the probability implied by the UDP checksum, anyway.
You should use TCP for this. TCP is for structured data that needs to arrive in a certain order without being dropped.
On the other hand, UDP is used when the packet becomes irrelevant after ~500 ms. This is used in games, telephony, and so on.
If your problem requires UDP, then you need to handle any lost, duplicate, or out-of-order packets yourself, or at least write code that is resilient to that possibility.
http://en.wikipedia.org/wiki/User_Datagram_Protocol
If you can't afford lost packets, then TCP is probably a better option than UDP, since it provides that guarantee out of the box.