I have used UDP protocol for sending packets to the receivers. Can anybody please tell me how can I guarantee that my udp packets are received at the receiver. I can not implement TCP protocol for some reasons. So please suggest that is there any mechanism by which I can guarantee that my packets are received at the receiver.
You cannot guarantee that your packets arrive at the receiver. All you can do is to check with the receiver that your packets have arrived there. And there is no builtin mechanism to do this - you are on your own to implement this.
This can be done for example by letting the receiver send an acknowledgement whenever a packet is received, by periodically asking the receiver which packets were received etc. The best way depends on your actual (and unknown) use case.
Of course this need to be explicitly implemented inside your application protocol and thus inside your applications on both sides of the communication.
Related
IS there a way I can in user-space get notification about a packet being dropped at Layer-2 in 802.11.
According to my understanding what happens is, when a packet is sent out on the medium, there are Layer-2 ACKs which are received if it is delivered correctly (if not,it does the retransmission and ultimately drops the packet if not delivered after several retries..)
I want to be able to access this notification (in user-space)and change the behavior of packet transmission.
I want to be able to send the packet to another host from the FIB rather than dropping the packet.
I have read about libpcap libraries and netfilter hooks which allows me to capture packet and inject them back on the networking stack..
But I'm not able to find hooks (if any, for the wireless stack) to help me capture the packet notification in Layer-2.
Please correct me if I'm not understanding something correctly. Also, any heads-up or links to read would be great.
No, you cannot, at least not using the standardised sockets interfaces. 802.11 is a link layer, and the sockets API is strictly link-layer agnostic: unless it's going to work on all link layers, it's not in sockets. There are good reasons for that: the kind of cross-layer interaction that you envision has been tried many times, and it's always turned out more trouble than it's worth.
You didn't give us any details about the application — but the best solution is most probably to change your application-layer protocol to send explicit acknowledgments, and send your data over the fallback route when you fail to receive an ACK.
So I see that there are methods provided to specify timeout value while sending data over UDP packets (at least saw that in C#). I was wondering what's the use of that as I thought UDP is a connectionless protocol and all the sender socket has to do is just send the packet without worrying about the packet being actually received. It makes sense to have a timeout on receive, but I am not sure why would you need a timeout on send. Can someone please explain?
That brings up another question, is UDP send blocking? (I would say not). If yes, what things does it get "blocked" on?
Thanks in advance.
Both questions have the same answer. send() just copies the datagram to the socket send buffer, which is then sent to the network by the OS in the background. If the buffer is full, it blocks. For UDP the buffer can fill up if you are sending datagrams faster than the OS can write them to the network.
Sockets can be either blocking (default) or non-blocking, whether they are TCP or UDP.
I have several apps which communicate through serial comm (RS-232 and RS-422), and i would like them to communicate through TCP or UDP without changing them. Another point is that some of the apps must run on linux.
I would like to know if there are exsiting tools for that purpose..
Thanks a lot!
Tal
If all you do with your serial port is read and write bytes, and if precise timing is not a concern, then you may be able to replace your serial port object with a TCP socket and send the exact same data over the socket as you would have sent over the port. The biggest complications are that the timing on a TCP socket is much looser than on a serial port, and TCP sockets' mechanisms for sending "out-of-band" data are different from those of a serial port.
I am unaware of any standards for sending serial data via UDP. Conceptually, it would seem like a useful thing to have since there are many serial-port protocols-based in which it would be more useful to drop data that can't be delivered within a certain time frame than to deliver it late. For example, if the intended recipient of serial-port data is an embedded controller that will sometimes so busy that it drops some incoming data, but which will respond within a few milliseconds to everything it does receive, a one-second hiccup on a TCP connection [not unusual] may cause software which expects to be talking directly to the controller to retransmit a command a dozen times. Even if the device would be capable of detecting and rejecting retransmissions it receives, it would be better for the earlier transmission requests to be abandoned than to have them be delivered late. Note that to be useful, a UDP-based scheme would have to include enough wrapper logic to guarantee that packets would never be delivered out of order; once the data for a packet has been sent to the serial port, any UDP packets which are received later despite having been sent earlier must be discarded; the recipient should probably include logic so that if many out-of-sequence packets are received, it will wait a little while after receiving any packet whose sequence number does not immediately follow the last one, to see if missing packets show up before it commits itself to discarding them.
There is no standard tool to do that. I am thinking to develop one. UDP is ideal in this case since it is 100% guaranteed that there is no out of order packet delivery on a short LAN as is in your case.
In several projects I have used free tool Hercules (https://www.hw-group.com/software/hercules-setup-utility) for protoyping and testing phases. No advertising intended, just a recommendation.
While sending packets across a network, how can one determine where one packet ends and where another starts?
Is sending/receiving acknowledgment one of the ways of doing so?
TCP is a stream-based protocol. That is, it provides a stream vs. packet or message-based interface to the application. If using TCP, an application must implement its own method of determining packets or messages. For example, (a) all message are a fixed size, or (b) each message is prefixed with its subsequent size, or (c) there is a special "end-of-record" sequence in the data stream to indicate a message boundary. Search google for lots of information on how one can implement message boundaries in TCP.
I assume here that you mean application-level 'packets'.
If you use UDP, you don't need to since it's a message protocol. TCP is a byte streaming protocol, so it cannot send packets, just bytes. If you need to send anything more complex than a byte-stream across TCP, you have to add another protocol on top - HTTP is one such protocol. Text is fairly easy since lines have terminating characters, usually CR/LF/CRLF. Sending non-text messages will require a different protocol.
One approach that is often used with TCP is to connect, stream a protocol-unit, disconnect. This works OK, but slowly because of the huge latency of continually opening and closing TCP connections. HTTP usually works like this in order to serve up web pages to large numbers of users who, if left permanently connected while they viewed pages, would needlessly use up all the server sockets.
Waiting for an application-level ACK from the peer is sometimes necessary if it absolutely essential that peer receipt is known before the next message is sent, but again, this is slow because of the connection latency. TCP was not designed with this approach in mind.
If the commonly available IP protocols cannot directly provide what you need, you will have to resort to implementing your own.
What sort of 'packet' are you sending?
Rgds,
Martin
With TCP sockets, you just see the datastream where you can receive and send bytes. You have no way of knowing where a packet ends and another begins.
This is a feature (and a problem) of TCP. Most people just read data into a buffer until a linefeed (\n) is seen. Then process the data and wait for the next line. If transferring chunks of binary data, one can first inform the receiver of how many bytes of data are coming.
If packet boundaries are important, you could use UDP but then the packet order might change or some packets might be lost on the way without you knowing.
The newer SCTP protocol behaves much like TCP (lost packets are resend, packet ordering is retained) but with SCTP sockets you can send packets so that receiver gets exactly the same packet.
UDP doesnot sends any ack back, but will it send any response?
I have set up client server UDP program. If I give client to send data to non existent server then will client receive any response?
My assumption is as;
Client -->Broadcast server address (ARP)
Server --> Reply to client with its mac address(ARP)
Client sends data to server (UDP)
In any case Client will only receive ARP response. If server exists or not it will not get any UDP response?
Client is using sendto function to send data. We can get error information after sendto call.
So my question is how this info is available when client doesn't get any response.
Error code can be get from WSAGetLastError.
I tried to send data to non existent host and sendto call succeeded . As per documentation it should fail with return value SOCKET_ERROR.
Any thoughts??
You can never receive an error, or notice for a UDP packet that did not reach destination.
The sendto call didn't fail. The datagram was sent to the destination.
The recipient of the datagram or some router on the way to it might return an error response (host unreachable, port unreachable, TTL exceeded). But the sendto call will be history by the time your system receives it. Some operating systems do provide a way to find out this occurred, often with a getsockopt call. But since you can't rely on getting an error reply anyway since it depends on network conditions you have no control over, it's generally best to ignore it.
Sensible protocols layered on top of UDP use replies. If you don't get a reply, then either the other end didn't get your datagram or the reply didn't make it back to you.
"UDP is a simpler message-based connectionless protocol. In connectionless protocols, there is no effort made to set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction, from source to destination without checking to see if the destination is still there, or if it is prepared to receive the information."
The machine to which you're sending packets may reply with an ICMP UDP port unreachable message.
The UDP protocol is implemented on top of IP. You send UDP packets to hosts identified by IP addresses, not MAC addresses.
And as pointed out, UDP itself will not send a reply, you will have to add code to do that yourself. Then you will have to add code to expect the reply, and take the proper action if the response is lost (typically resend on a timer, until you decide the other end is "dead"), and so on.
If you need reliable UDP as in ordering or verification such that TCP/IP will give you take a look at RUDP or Reliable UDP. Sometimes you do need verification but a mixture of UDP and TCP can be held up on the TCP reliability causing a bottleneck.
For most large scale MMO's for isntance UDP and Reliablity UDP are the means of communication and reliability. All RUDP does is add a smaller portion of TCP/IP to validate and order certain messages but not all.
A common game development networking library is Raknet which has this built in.
RUDP
http://www.javvin.com/protocolRUDP.html
An example of RUDP using Raknet and Python
http://pyraknet.slowchop.com/