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.
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 need to have an intelligent conversation with several co-workers who have not yet been sold on embracing tried and trusted message queuing libraries such as MSMQ, ZeroMQ, RabbitMQ, etc and we need this type of messaging in our solution.
But to be able to sell to my colleagues the benefits of using established solutions, I need to understand the fundamental difference between PGM and UDP. What is PGM solving that UDP multicast could not solve?
The fundamental difference:
UDP multicast is not reliable meaning messages may be lost or delivered out of order,If you want delivery guarantees you will have to build middleware on top to handle this.On the other hand PGM is a reliable multicast protocol meaning you get in order message delivery guarantees "out of the box" PGM
I am creating a server on a ST Cortex M3 device. I am using the lwip API and FreeRTOS. All is working, but the response time is way off. I am currently using lwip 1.3.2 and FreeRTOS 7.3.
A single client connects to the server and must have some time-critical data sent frequently. These packets are on the order of 6 or so bytes. Other times, I am sending upwards of 20K.
The problem I am having is that these smaller packets seem to be taking forever to be sent. I assume this is because lwip is waiting for more data to be enqueued to make more efficient transmissions. I cannot wait around for 2 or 3 seconds for the data to be sent; the client is expecting the data nominally in a few micro-seconds or milli-seconds.
I have tried using lwip_send and lwip_write. (I understand that one is the same as the other with a flag passed at the end. Just had to try...) I have tried setting TCP_NODELAY on the socket to no avail. I tried to set SO_SNDLOWAT to '1', but this always returned -1, so I do not think it is supported.
I do not want to redo all of my code using TCP RAW. Is there a way to invoke the tcp_output() function outside of TCP RAW mode? Is there any way to speed things up or is this just how slow lwip TCP with small packets is?
Any and all suggestions are welcome. Thanks.
--EDIT--
I would also like to add that once I am ready to transmit, I make sure that my TX task in FreeRTOS is at the highest priority. There are no other tasks running up to the point at which I call lwip_send/write.
I'm fairly experienced with bare metal lwIP on xilinx and lwip does not wait to send things out. It will pump packets out as fast as your interrupts are acknowledged based on the ethernet hardware. I've been using UDP only. What is coming to mind though, is your problem might be on the receive end. If you are doing TCP, maybe those small packets are coming out late because you are having receive issues. What you need to do is find in the code the lowest level point at which ethernet is transmit, put a general purpose output toggle on that. Then also put a general purpose output toggle on when a ethernet packet is received. Look at the signals on a scope. If it confirms your hypothesis, then move the output toggles around to narrow down the issue. Wash, rinse and repeat until you are down to where the issue its. It's crude and time consuming, but oftentimes this brute force approach solves many "impossible" embedded software problems, due to pure determination. Good luck!
Hi I am writing a program that will send a file from client to server using UDP socket using different packet sizes for example 512B, 1KB and 2KB and i don't want use fixed buffer size in the receiver(server).I need some codes in Java that will allow both server and client to agree upon a packet size before transfer start. Many thanks
Don't you forget that UDP packets may be fragmented, duplicated and lost? There is a whole bunch of things to take care of, starting with lost packet retransmissions.
I hate to give a "don't do this" kind of answers, but for this one, just use TCP. And if you want some user-level "packets", you can have them with TCP also (prefix each one with its length, that's enough).
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.