I'm working on embedded development on UDP socket programming. What all do I need to know? How to make the connection manually? but specifying the ports and memory addresses?
UDP is a connection-less transport. There is no "connection". You specify the destination IP/Port on each individual datagram you send.
Related
I am working on making a port scanner . I can check whether ports are open or not by trying to make a connection with the port but, how I will check the open port is udp or tcp?
... how I will check the open port is udp or tcp?
What you seem to have in mind is a single street where the ports are house numbers and in each house TCP and/or UDP might live. And you knock on the door and then need to figure out if UDP or TCP opened the door. But this view is wrong.
It is more like two separate streets which just have the same house numbers. There is one street for TCP and another for UDP and you decide which street to walk by choosing the type of socket. No need to check who is living in there since in the TCP street only TCP can live and in the UDP street only UDP.
A TCP socket gets created with AF_INET (or AF_INET6) and SOCK_STREAM. A UDP socket uses SOCK_DGRAM instead of SOCK_STREAM. So you know by creating the socket what you expect, i.e. which street to walk.
Apart from that UDP does not have the concept of an actual connection: while one can connect a UDP socket this will set the destination address on the local socket. It does not actually send any data to the peer to establish a connection like done with TCP. Thus a connect on a UDP socket will basically always succeed, no matter if something is expecting traffic on the destination (i.e port is "open") or not.
A single port can have any number of services running on it, using different protocols. Connecting only means that you connected with a specific protocol, and you'll need to check the other(s).
So, while it's probably unsatisfying as an answer, if you've been probing with TCP, you've probably never found a UDP service, and vice versa. And if you've been probing with XTP or something similarly obscure you've probably never found an open port.
Of course, be careful. "Connection" has different meanings under different protocols, particularly the stream-oriented protocols like TCP. You might have "connected" in an informal sense (provoked the server to acknowledge you), but you may not be "connected" in the sense of establishing a connection where the you definitely have the server's attention.
I am building an application that will deploy in effect on multiple "clients" with a common "server". Clearly I could communicate between each client and the server using a single read-write socket for each client-server link, or a read socket and a write socket per link if I really wanted to.
But what if there are (hopefully good) reasons that the server wants to read from any client, and broadcast back to all? If you have a connectionless protocol like UDP, can the server use only a single read-write socket, or must it use one for reading and one for writing? What about the clients? And does this change if you use a connection-based protocol like TCP?
If you have a connectionless protocol like UDP, can the server use only a single read-write socket, or must it use one for reading and one for writing? What about the clients? And does this change if you use a connection-based protocol like TCP?
A socket as an endpoint which has at least a local address and port in case of UDP and TCP. Only data received for this ip and port are delivered to the socket and all data send from this socket contain the local ip and port as the source. A socket can be connected, in which case also the destination IP and port is known. With TCP a socket needs to be connected, with UDP not.
This means:
You can use the same unconnected UDP socket to send data to multiple peers (destination is an argument for the sendto function). You cannot do this with TCP, i.e. you need a connected socket for each single peer.
You can receive data from multiple peers on an unconnected UDP socket. You cannot do this with TCP.
The special broadcast address can be used with UDP but not with TCP, since with TCP you need to have a connection between only two clients which is not the case with broadcast.
See also a related question with answer for more information: Bidirectional UDP Multicast
But what if there are (hopefully good) reasons that the server wants
to read from any client, and broadcast back to all?
Well, then you'd probably want to use a UDP socket (either instead of, or in addition to, some TCP sockets) :)
If you have a connectionless protocol like UDP, can the server use
only a single read-write socket, or must it use one for reading and
one for writing?
A single UDP socket is sufficient for both reading and writing (although some multithreaded designs might find it easier to use two separate sockets instead; either way will work).
What about the clients?
Clients can also use a single socket for both sending and receive UDP packets, if that's what you're asking.
And does this change if you use a connection-based protocol like TCP?
With TCP sockets you can also use a single socket for both sending and receiving. However you will need one TCP socket for each destination that you want to send or receive to/from. (Contrast this with UDP where a single UDP socket can be used in conjunction with sendto() or recvfrom() to communicate with multiple peers)
As per your requirement, you have two ways :
By using TCP connection only : Server reads message from client and for the broadcasting to all clients,server writes message to all client's TCP sockets(connected to clients) and clients read that message from TCP socket(connected to server).This method requires that client and server knows the IP addresses of each other
By using TCP connection for the client-server direct communication and UDP for broadcasting : In this method,client and server communicates (directly one to one) using TCP connection. For broadcasting the message, server can broadcast the message over the network using UDP socket and clients have UDP broadcast receiver for receiving the broadcast message.
So I know how to broadcast a packet on the LAN (send it to x.x.x.255) IP. I am confused on how to receive the packet on the receiving host. Like i don't know what kind of socket connection I need to use. Please help me. Thanks
You need to use UDP sockets. At receiving side just keep on listening like any normal UDP socket. No special setup is needed.
I know that with TCP each connection creates a new socket. Does UDP also create a new socket for each connection?
No.
When you receive a message (recvmsg()), you are told the IP address of the peer that sent the message; when you respond (sendmsg()), you specify the IP address to which the message goes. This is done over a single socket. See also <sys/socket.h>.
I know that with TCP each connection creates a new socket.
You have that back to front. Each new socket represents a new connection.
Does UDP also create a new socket for each connection?
That doesn't make sense either. First there are no real connections in UDP. Second, it is you who creates the sockets, or your application. Not UDP. Or TCP.
For an UDP server architecture that will have long-lived connections, one architecture is to have one socket that listens to all incoming UDP traffic, and then create separate sockets for each connection using connect() to set the remote address. My question is whether it is possible to do this atomically similar to what accept() does for TCP.
The reason for creating a separate socket and using connect() is that this makes it easy to spread the packet-processing across multiple threads, and also make it easier to have the socket directly associated with the data structures that are needed for processing.
The demultiplexing logic in the networking stack will route the incoming packets to the most specific socket.
Now my question is basically what happens when one wants to emulate accept() for UDP like this:
Use select() with a fd-set that includes the UDP server-socket.
Then read a packet from the UDP server-socket.
Then create a new UDP socket which is then connect()ed to the remote address
I call select() with a fd-set that includes both sockets.
What is returned?
given that a packet arrives to the OS somewhere between 1 and 3.
Will the packet be demultiplexed to the UDP server-socket, or will it be demultiplexed to the more specific socket created in 3. That is, at what point does demultiplexing take place? When the packet arrives, or must it happen "as if" it arrived at point 4?
Follow-up question in case the above does not work: What's the best way to do this?
I see that this discussion is from 2009, but since it keeps popping up when I search, I thought I should share my approach. Both to get some feedback and because I am curios about how the author of the question solved the problem.
The way I chose emulate UDP-accept was a combination of number one and two in nik's answer. I have a root thread which listens on a given socket. I have chosen to use TCP for simplicity, but changing this socket to UDP is not very hard. When a client wants to "connect" to my server using UDP, it first connects to the TCP socket and requests a new connection.
The root thread then proceeds by creating a UDP socket, binds it to a local interface, does connect and sets up data structures. This file descriptor is then passed to the thread that will be responsible for the connection. The IP/port information of the new UDP socket is passed back to the client, which creates a new UDP socket and sends data to the provided IP/port.
This approach works well for my use, but the additional steps for setting up a flow introduces an overhead. In some cases, this overhead might not be acceptable.
I found this question after asking it myself here...
UDP server and connected sockets
Since connect() is available for UDP to specify the peer address, I wonder why accept() wasn't made available to effectively complete the connected UDP session from the server side. It could even move the datagram (and any others from the same client) that triggered the accept() over to the new descriptor.
This would enable better server scalability (see the rationale behind SO_REUSEPORT for more background), as well as reliable DTLS authentication.
This will not work.
You have two simple options.
Create a multi-threaded program that has a 'root' thread listening on the UDP socket and 'dispatching' received packets to the correct thread based on the source. This is because you want to segregate processing by source.
Extend your protocol so the the sources accept an incoming connection on some fixed port and then continue with the protocol communication. In this case you would let the source request on the standard UDP port (of your choice), then your end will respond from a new UDP socket to the sources' UDP port. This way you have initiated a new UDP path from your end backwards to the known UDP port of each source. That way you have different UDP sockets at your end.