I have 2 UDP sockets (SOCKET), one for sending and one for receiving on a Windows machine. They both work well, but the trouble is that a program that is receiving messages from my send socket replies to the same port which sent the message.
I know that if I don't bind the send socket, using sendto will pick an ephemeral port to send on.
I'd like to know if it is possible to any of the following, and if so, what is the recommended way to do it:
Bind both the send and receive sockets to a chosen port so that when the external program sends a message back it can be received.
Update the port to which the receive socket is bound in such a way as to receive on the port from which I last sent a message (not sure if this would create a race condition).
Some other correct method.
So far I have tried:
Not binding the send socket (it sends from some open port to the destination port). I can successfully receive messages on that port for as long as it doesn't change, but eventually it does change.
Binding both the send and receive sockets to a desired port. This creates the desired behaviour when I watch the packets using a sniffer, but the receive socket never receives the messages even though I see them being transmitted to the correct port and IP.
Packets are being received from more than one outside entity, and not guaranteed to be in any particular order.
Thank you in advance!
Looks like you are trying to use threads to separate sending and receiving data. I would question this approach, since UDP is so easy to handle in one thread. Nevertheless, you can just use the same socket from both threads if you want (see related question: Are parallel calls to send/recv on the same socket valid?). Just bind(2) it and, optionally, connect(2) it.
Related
i wrote a multithreaded UDP server after the following scheme:
Scheme:
1 Receiver Thread
(Multiple Worker Threads, each has an own Socket, not bindend ,just created Ipv4, UDP,Datagram)
Message gets pushed to 1 worker which then proceed's it and then sends an answere with its own socket.
Problem:
This works perfectly on all my own test programs but for some odd reason it doesnt work with an old software for what i am emulating the server. The software uses async Wsa (overlapped), but i still doesn't get why it doesnt work.
Confusion:
It works if I use the same socket for sending as i used for receiving the data on the serverside. I dont get why, udp is a connectionless protocol so how can it detect a different socket?
Confusion: It works if I use the same socket for sending as i used for
receiving the data on the serverside. I dont get why, udp is a
connectionless protocol so how can it detect a different socket?
If you look in the UDP headers of the packets you are sending you will notice that they contain a "UDP Source Port" field. That field can be examined by the receiver of the packet (via recvfrom()) to find out which UDP port the sending UDP socket used on the sending machine (note that this is different from the "UDP Destination Port" field that determines which port the packet should be delivered to on the receiving machine). It's possible that in your case, the program you are communicating with is looking at that field and adjusting its behavior based on that field's value.
If you're wondering what that field will be set to if you never called bind() on the sending UDP socket, the answer is that the OS will choose an available UDP port number to send from (essentially an implicit bind()).
I have some issues getting information about the acknowledgement of a TCP connection.
I've implemented a basic TCP Socket Server (socket(), listen(), bind(), accept(), send()) using Windows sockets. The communication works fine but now I want to retrieve and observe the incoming acknowledgements of the TCP packet.
Does anyone knows how I can get this information programmatically?
If your application needs to know when the data is received, or even in the case of failure, how much was received, you need an application-level acknowledgement.
The TCP ACK does not belong to the Application layer, it is purely layer-4 book-keeping information. If layer7 needs an ACK you need to add one at layer 7.
Related, the same goes for keep-alives: Asyncsockets and "silent" disconnections
Dear Stackoverflowers,
I am researching networking a bit and I decided I'd like to create a small and simple networking library with Winsock. (I am using Completion Ports and Overlapped IO though)
As I researched a bit I came to the following steps for a TCP Listener(Correct me if I am wrong):
Create a Listening Socket
Bind it to a port/IP
Listen on it
When a new connection is created, give a seperate Socket for that connection.
Listener continue's to listen, the specific connection is handled as needed.
EDIT: With a 'connection' from here I mean communication between the server and distinct clients.
Though for an UDP Listener we need to make use of WSARecvFrom which returns the IP address at the lpFrom parameter. Now I was wondering the following:
Is it better to make one UDP Socket listen to incoming connections on a specific port with WSARecvFrom and create new sockets for every specific connection? Or could I just use the UDP Socket itself with WSASendTo. Would that cause any performance penalties if one UDP Socket is used for for example 1000 connections? Or would it be the same or even better then creating/duplicating seperate Sockets for each different incoming connection?
Note: If multiple sockets are needed how would you handle sockets listening on the same port or could a client accept UDP from different ports?
Hope you guys can help!
Ps. Extra tips are always welcome!
Unlike TCP, UDP is connection-less, and as such you don't need to create separate sockets for each party. One UDP socket can handle everything. Bind it to a local IP/Port and call WSARecvFrom() once, and when it reports data to your IOCP you can process the data as needed (if another thread if needed) and then call WSARecvFrom() again. Each time new data arrives, you have to look at the reported lpFrom address to know the IP/Port of the sender. And yes, you can use the same UDP socket for sending data to each sender when needed.
I am pretty new to socket programming - so this might be a simple question but I'd really like to clarify.
I have a multiple-client to single server program: the individual clients send messages to the server which processes them, and then passes it on the destination i.e. the server is an intermediary.
On the server side, there is one thread for each client which is meant to 'listen' for messages from the clients (which will be placed in a buffer). At the moment all the clients are sending messages to the same port (as far as I can tell).
I am thinking of setting up another thread on which the server will process the messages before transmitting them on. Does it make sense to use another port on the server to send those messages?
I don't mean this to be a discussion, but I don't know what is common or more logical to do - any advice?
On the client-side, I am planning for it to have one thread for sending messages to the server, and another thread for receiving. Please let me know if any other information is required!
edit
At the moment it is a 1-server-to-multiple(tens now, hundreds later)-client program - I seem to have problems with the client receiving messages from my server (I am troubleshooting so I thought that using the same ports might be the problem), but I will try it with the same ports again and see. I thought it might be a matter of the receiving port being too busy to send messages as well.
At the moment all the clients are sending messages to the same port (as far as I can tell).
What do you mean 'as far as I can tell'? You must know whether you are opening more than one port at the server.
Does it make sense to use another port on the server to send those messages?
No it doesn't. If you're using TCP, send the messages back down the same socket. If you're using UDP you don't need more than one UDP socket, and it simplifies the client and the application protocol if replies come from the same ip:port the request was sent from.
For my Uni assignment I have to create a fast action paced networked game and so have chosen to use UDP as opposed to TCP. I am aware of a lot of the differences in programming both UDP and TCP and have read through most of the relevant parts of MSDN's documentation on winsock. On MSDN it states that creating a UDP socket via the connect() function should bind the socket to the address and port specified and as a result be able use the send() and recv() functions with the created socket.
For my application I create a client and use connect() using the loopback address which sends a number of packets via the send() function. The client, after calling select(), then receives the packets it sent out. However the result I get from the recv() function is SOCKET_ERROR and the error description using WSAGetLastError() is "An existing connection was forcibly closed by the remote host".
If i use the bind() function and use sendto() to send data over the loopback address, I recv() packets without any errors... Does anyone know why the connect() function is not doing what it is supposed to do, and has anyone been able to use UDP sockets with the connect() function?
You will need to call bind() if you want your program to receive UDP packets. connect() only sets the address that the socket will send packets to if you call send(); it does not associate the socket with a local UDP port to receive on; for that you must call bind().
"UNIX Network Programming" points out that a connect call made on a UDP client side socket figures out and stores all the state about the destination socket address in advance (masking, selecting interface, etc.), saving the cost of doing so on every ::sendto call. This book claims that ::send vs ::sendto can be up to 3x faster because of this reduced overhead - data can go straight to the NIC driver bypassing most IP stack processing. High performance game programmer's may want to consider this.
you should check Beej's Guide to Network Programming Using Internet Sockets, there are nice examples that address your question.
Keep in mind that the UDP protocol is a "connectionless" protocol meaning that you never ever connect to the host, you just send out data. So you can see that connect as an action is meaningless for UDP.
For UDP you should use sendto() and recvfrom() in these function you specify the address and the buffers and that's about it, everything else that is comfortably handled for you in TCP is gone you have to handle things on your own.
In the MSDN documentation its mentioned that you can in fact somehow use the normal send/recv functions with UDP but why would you when you have separate functions already? Like other commented already connect() for UDP does something else it's not essentially a "connect" operation but a sort of a filter to set up send()/recv() for UDP usage.