I have a question where 2 or more client on host A try to receive from host B with exactly the same address and port number.
Suppose we have host A and there are 2 thread running on it. A.thread_a sends a packet to B port xxxx. Then it does recvfrom(B, xxxx). At the same time, A.thread_b does the same recvfrom() call with same IP and port number. B, after receiving request from A.thread_a, sends data by sendto(A, yyyy). Who would receive the response, A.thread_a or A.thread_b?
If you want to multiplex message-streams from multiple threads, you should put some sort of originator-ID in the message and have the peer return it in the response. – Martin James
Related
My server is using a single udp socket to receive udp streams from different ip addresses. (All senders send to the same port).
When recv returns on the server with a chunk of data, might that chunk contain bytes from different sources?
Assuming not, is there a reliable way to determine which sender sent that entire chunk?
In UDP, each chunk received will be exactly what a sender previously passed to ‘send()’ or ‘sendto()’ — unlike TCP, UDP maintains message boundaries.
You can find out the IP address and port the received packet was sent from by calling ‘recvfrom()’ instead of ‘recv()’. Those values will be written into the ‘struct inaddr_in’ that you provide a pointer to.
I have a client application that uses IOCP for socket communication. I'm using ConnectEx to make the TCP connection to the remote endpoing (binding the socket to ADDR_ANY and port 0 before calling ConnectEx).
It will be valid to have two connections to the same remote endpoint (same IP address and port number). When I test that condition with my current code, I have two overlapped IO read operations outstanding (one on each connected socket) from calls to WSARecv(). Each WSARecv() is called with the correct socket and overlapped structure. For example: WSARecv(socket1, ... overlapped1) and WSARecv(socket2, ... overlapped2). The problem I've run into is that when I get a response back from either remote, it triggers the completion event for both of the outstanding overlapped operations. My code only produces this result when two remotes have the same ip address and port number, not when there are two unique remote addresses. Is this the expected behavior (hopefully not)? If so, is there another way to accomplish this?
I'm posting an answer, even though it is really just an explanation of why the problem happened.
My test involved connecting to and communicating with a remote device that provides data. It turns out that it is on the other side of a digi terminal server. So the connection path was:
my test computer (via TCP) -> Digi terminal server (via Serial) -> remote device.
The digi terminal server basically converts TCP/IP to serial communications, and back. Since the serial side doesn't have a concept of 'connectedness' the digi doesn't know which TCP/IP connection should receive the serial data in response to a TCP/IP request, so it forwards the serial data to all active connections on the TCP/IP side. That's what was producing the IOCP trigger on both of my pending overlapped operations. Every time a request was sent to the digi, it sent the request out of its serial port. When the end device responded, the digit forwarded the response data to each of my TCP/IP connections.
Thanks to everyone who commented on my question, but sorry for taking up your time.
I am Developing a VOIP softphone, I need to put RTP port number in SDP part in my INVITE Request. how can I find a free UDP port number to accept RTP packets.
I have found 2 solutions but don't know if they are correct way to do this.
Solution 1 : start from a UDP port number (say 7000) and see if its free , if not increase by 1 and continue until a free port is found. then open a UDP socket on that port , so that other calls can't choose my calls RTP port.
then send the request.
Solution 2 : start from a UDP port number (say 7000) and see if it's free, put it in SDP and send the request. but when I get OK response from other party (after a while), there is no guarantee that the port number I announced for RTP is still available. maybe other call has captured that.
I would like to know what is the best way to do this.
As AymericM suggested, you should stick to your solution 1.
You need to use the bind call to bind a socket to a port.
Additionally, the RTP specification states that the RTP port should typically be even, with the RTCP port being the rtp_port + 1.
For UDP and similar protocols,
RTP SHOULD use an even destination port number and the corresponding
RTCP stream SHOULD use the next higher (odd) destination port number.
Even in the case where you support RTP/RTCP multiplexing over a single port, the answerer might not, so it might be a good idea to bind both the RTP and RTCP ports when generating the offer.
So to summarise, try to bind two consecutive ports starting on an even number and once you've found two suitable ports, generate the offer/INVITE.
Solution 1 is the only way to reserve a port number within a specific range of port.
If you do not care about being close to a specific port number, just open a port with value 0 in order to get a random port which will of course be free. Then, retrieve the real opened port with socket's API and use it in your sdp!
Does UDP allow two clients to connect at the same time to a server port?
DatagramSocket udp1 = new DatagramSocket(8000); // = localhost:8000 <-> ?
DatagramSocket udp2 = new DatagramSocket(8000);
What happens if udp1 and udp2 are created from two different IPs and send data at the same time?
Will it cause any issue?
Note: UDP doesn't really have a concept of "connect", just sending and receiving packets. (e.g. if making a TCP connection is analogous to making telephone call, then sending a UDP packet is more like mailing a letter).
Regarding two sockets arriving at the same UDP port on a server at the same time: the TCP/IP stack keeps a fixed-size receive-buffer for each socket that the server creates, and whenever a packet arrives at the port that socket is bound to, the packet is placed into that buffer. Then the server program is woken up and can recv() the data whenever it cares to do so. So in most cases, both packets will be placed into the buffer and then recv()'d and processed by the server program. The exception would be if there is not enough room left in the buffer for one or both of the packets to fit into it (remember it's a fixed-size buffer); in that case, the packet(s) that wouldn't fit into the buffer will simply be dropped and never seen again.
Say Server S have a successful TCP connection with Client C.
C is keep sending 256-byte-long packets to S.
Is it possible that one of packets only receive part of it, but the connection does not break (Can continue receive new packets correctly)?
I thought TCP protocol itself will guarantee not lose any bytes while connecting. But seems not?
P.S. I'm using Python's socketserver library.
The TCP protocol does guarantee delivery. Thus (assuming there are no bugs in your code and in the TCP stack), the scenario you describe is impossible.
Do bear in mind that TCP is stream- rather than packet-oriented. This means that you may need to call recv() multiple times to read the entire 256-byte packet.
As #NPE said, TCP is a stream oriented protocol, that means that there is no guarantee on how much data bytes are sent in each TCP packet nor how many bytes are available for reading in the receiving socket. What TCP ensures is that the receiving socket will be provided with the data bytes in the same order that they were sent.
Consider a communication through a TCP connection socket between two hosts A and B.
When the application in A requests to send 256 bytes, for example, the A's TCP stack can send them in one, or several individual packets, or even wait before sending them. So, B may receive one or several packets with all or part of the bytes requested to be sent by A, and so, when the application in B is notified of the availability of received bytes, it's not sure that it could read at once the 256 bytes.
The only guaranteed thing is that the bytes B reads are in the same order that A sent them.