A very basic socket question
-
If I have two UDP sockets bound in the following manner: 1. INADDR_ANY, port number 0 (all ports?) 2. 10.3.2.1, port number 0 (all ports again) A. Send a message using socket 2. The source port picked by Windows is 1350 (as an example). B. Reply comes back to destination port 1350, IP = 10.3.2.1. Where should this message be rcvd? If a thread is looping doing a rcvfrom on socket 1, it never sees this reply. I never do a rcvfrom on socket 2, but I am guessing that I would see the reply if I did. I'm wondering why the first socket cannot rcv this message? I am not an experienced sockets programmer at all, and I am hoping this is a simple issue. Thanks, David
You have to select some predefined UDP port for this to work (some random number should do, as e.g. 27890), and bind both sockets to it before sending and receiving. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
If I have two UDP sockets bound in the following manner: 1. INADDR_ANY, port number 0 (all ports?) 2. 10.3.2.1, port number 0 (all ports again) A. Send a message using socket 2. The source port picked by Windows is 1350 (as an example). B. Reply comes back to destination port 1350, IP = 10.3.2.1. Where should this message be rcvd? If a thread is looping doing a rcvfrom on socket 1, it never sees this reply. I never do a rcvfrom on socket 2, but I am guessing that I would see the reply if I did. I'm wondering why the first socket cannot rcv this message? I am not an experienced sockets programmer at all, and I am hoping this is a simple issue. Thanks, David
the port 0 is not all, but a default port selected by system. client must know which port the server is on, otherwise u can't establish a socket connection. includeh10
-
the port 0 is not all, but a default port selected by system. client must know which port the server is on, otherwise u can't establish a socket connection. includeh10
Thank you for the replies. When my listening socket binds to IN_ADDRANY, and I pass port 0 to the bind call, doesn't that mean that I can rcv messages from any port number? This should be true, since this is the part that has been working for quite a while. I realize that when I send a message, that the O/S will pick a source port, but when I do a rcvfrom, won't I be able to catch messages from any UDP port? Sorry for the stupid questions, I can't seem to find any documentation on this type of a bind call. Thanks again.
-
Thank you for the replies. When my listening socket binds to IN_ADDRANY, and I pass port 0 to the bind call, doesn't that mean that I can rcv messages from any port number? This should be true, since this is the part that has been working for quite a while. I realize that when I send a message, that the O/S will pick a source port, but when I do a rcvfrom, won't I be able to catch messages from any UDP port? Sorry for the stupid questions, I can't seem to find any documentation on this type of a bind call. Thanks again.
think a socket is just a wire from one port of client to one port of server. client can use port 0 (it may be 1350 actually) but client must know port used by server (server is listening on the port). server is pastive and client is positive for first connection. includeh10
-
think a socket is just a wire from one port of client to one port of server. client can use port 0 (it may be 1350 actually) but client must know port used by server (server is listening on the port). server is pastive and client is positive for first connection. includeh10
Thanks again. The software is not really a client/server application, although I guess you could think of it that way. The PC communicates with remote units by sending messages, and waiting for replies, but the PC also looks for any unsolicited messsages, and deals with them as well. So, in this regard the PC must act as the server, and client. This is why the listening socket needs to be able to read messages from unkown sources (and this has been working). Anyway, I think I'll leave it as it is, and find another way to send and recv the new message (without breaking what has been working). Thanks again for your replies.
-
Thank you for the replies. When my listening socket binds to IN_ADDRANY, and I pass port 0 to the bind call, doesn't that mean that I can rcv messages from any port number? This should be true, since this is the part that has been working for quite a while. I realize that when I send a message, that the O/S will pick a source port, but when I do a rcvfrom, won't I be able to catch messages from any UDP port? Sorry for the stupid questions, I can't seem to find any documentation on this type of a bind call. Thanks again.
Dave_ wrote: When my listening socket binds to IN_ADDRANY, and I pass port 0 to the bind call, doesn't that mean that I can rcv messages from any port number? This should be true, since this is the part that has been working for quite a while. No, that's not correct. When you recieve a message you must use, aka bind to, a port number known to both computers ahead of time. The reason is the client (or sending machine) must know which port to send its message to. The server can only listen on one port at a time. Like someone else pointed out, pick some high random number (below 65535 though) so you don't interfere with ports that have official uses ( those < 1024). It's like a telephone number. When someone calls you they must know your phone number. You don't care what number they're calling from (that's where IN_ADDRANY comes from), but you'll always be to receive calls at your number. Don't feel estranged.... socket programming is pretty goofy when you first start doing it.
-
Dave_ wrote: When my listening socket binds to IN_ADDRANY, and I pass port 0 to the bind call, doesn't that mean that I can rcv messages from any port number? This should be true, since this is the part that has been working for quite a while. No, that's not correct. When you recieve a message you must use, aka bind to, a port number known to both computers ahead of time. The reason is the client (or sending machine) must know which port to send its message to. The server can only listen on one port at a time. Like someone else pointed out, pick some high random number (below 65535 though) so you don't interfere with ports that have official uses ( those < 1024). It's like a telephone number. When someone calls you they must know your phone number. You don't care what number they're calling from (that's where IN_ADDRANY comes from), but you'll always be to receive calls at your number. Don't feel estranged.... socket programming is pretty goofy when you first start doing it.
Thanks for taking the time to look at this for me. The application is not actually a server. There are two threads, one for sending, and one for receiving. When the PC sends a message, it will send using a constant source port number of 1594. The hardware responds to that port number, but the PC also needs to listen for unsolicited messages from other port numbersd. This part of the software has been working for years without problems. I don't understand how I could possibly be recieving messages if when I pass in IN_ADDRANY, and 0 for the port number, and that results in a port number 1679 (for example) after the bind, since most messages (if not all) are coming in on port 1594? Thanks again, sorry for the lack of knowledge.
-
Thanks for taking the time to look at this for me. The application is not actually a server. There are two threads, one for sending, and one for receiving. When the PC sends a message, it will send using a constant source port number of 1594. The hardware responds to that port number, but the PC also needs to listen for unsolicited messages from other port numbersd. This part of the software has been working for years without problems. I don't understand how I could possibly be recieving messages if when I pass in IN_ADDRANY, and 0 for the port number, and that results in a port number 1679 (for example) after the bind, since most messages (if not all) are coming in on port 1594? Thanks again, sorry for the lack of knowledge.
Dave_ wrote: The application is not actually a server. There are two threads, one for sending, and one for receiving. This is fine and makes sense. Dave_ wrote: When the PC sends a message, it will send using a constant source port number of 1594. This does not. The source port number applies when you are *sending* a message and should be determined by the operating system when you create the socket. This should not be a constant. The reason is you have no way of knowing (realistically) what ports are being used, so the OS takes care of it for you. To help clarify: 1. Computer A wants to send a message to computer B 2. Computer B binds to a port (say 2000) 3. Computer A opens a socket connection to B and the OS assigns it a port of 47826 (essentially random from A's point of view) to use 4. Computer A sends a message to port 2000 on B Now, from A's point of view, 2000 is the *destination* port, and 47826 is the *source* port. Dave_ wrote: I don't understand how I could possibly be recieving messages if when I pass in IN_ADDRANY, and 0 for the port number, and that results in a port number 1679 (for example) after the bind, since most messages (if not all) are coming in on port 1594? See, if your messages are coming in on port 1594 then your server must be listening on the same port to receive them. That's why, for the receiving computer, it doesn't make sense to dynamically let the OS determine the port to bind to. You'll want to explicitly bind to port 1594, not 0. Forgive me if I'm missing something, but I hope that clears up what I'm trying to say.
-
Dave_ wrote: The application is not actually a server. There are two threads, one for sending, and one for receiving. This is fine and makes sense. Dave_ wrote: When the PC sends a message, it will send using a constant source port number of 1594. This does not. The source port number applies when you are *sending* a message and should be determined by the operating system when you create the socket. This should not be a constant. The reason is you have no way of knowing (realistically) what ports are being used, so the OS takes care of it for you. To help clarify: 1. Computer A wants to send a message to computer B 2. Computer B binds to a port (say 2000) 3. Computer A opens a socket connection to B and the OS assigns it a port of 47826 (essentially random from A's point of view) to use 4. Computer A sends a message to port 2000 on B Now, from A's point of view, 2000 is the *destination* port, and 47826 is the *source* port. Dave_ wrote: I don't understand how I could possibly be recieving messages if when I pass in IN_ADDRANY, and 0 for the port number, and that results in a port number 1679 (for example) after the bind, since most messages (if not all) are coming in on port 1594? See, if your messages are coming in on port 1594 then your server must be listening on the same port to receive them. That's why, for the receiving computer, it doesn't make sense to dynamically let the OS determine the port to bind to. You'll want to explicitly bind to port 1594, not 0. Forgive me if I'm missing something, but I hope that clears up what I'm trying to say.
We (here at my company) have talked about the reasons why the original programmer bound the sending port to 1594. I realize this is not the normal thing to do, but given that it is currently done this way, does the rest of it make sense? We have officially "reserved" UDP 1594 for our systems, so that's why we are not randomly picking one. So when we send, we know that the units are going to reply to port 1594, since we know that we sent on 1594. The only thing left to sort out is how the listening socket works. If it is bound with IN_ADDRANY, and port 0, there is next to no chance that it is picking 1594 (at least not every single time). So, given that it does actually get messages from 1594, I'm assuming that doing a rcvfrom on this type of bind will let me recv. from unkown port numbers, and not just 1594, since I never used the number "1594" anyhwere near the listeners source code. This is where I am confused. Most people use sockets the way you described, where the client sends to a known server port, and things interact from there, but this is done differently. In this case, the PC sends most of the initial messages, and waits for replies, but it also collects messages from other ports, such as 502 (Modbus protocol). I hope I am not sounding like I know more than you do, because I'm sure this is not true, but when it comes to the operation of the existing code, I do know that it works as I described. There are probably better ways to do it, however. When I wanted to add a third socket to send a broadcast message, things didn't work, so I started to look further into it. The broadcast would go out each NIC, but the source IP was always the primary NIC's IP. So the new socket was created and bound to each NIC's IP, and port 0. The broadcasts were sent properly, but the replies were never seen by the listener. That's how I got to this point. Sorry for the novel. I'll understand if you want to ignore me now. Thanks again, David.
-
We (here at my company) have talked about the reasons why the original programmer bound the sending port to 1594. I realize this is not the normal thing to do, but given that it is currently done this way, does the rest of it make sense? We have officially "reserved" UDP 1594 for our systems, so that's why we are not randomly picking one. So when we send, we know that the units are going to reply to port 1594, since we know that we sent on 1594. The only thing left to sort out is how the listening socket works. If it is bound with IN_ADDRANY, and port 0, there is next to no chance that it is picking 1594 (at least not every single time). So, given that it does actually get messages from 1594, I'm assuming that doing a rcvfrom on this type of bind will let me recv. from unkown port numbers, and not just 1594, since I never used the number "1594" anyhwere near the listeners source code. This is where I am confused. Most people use sockets the way you described, where the client sends to a known server port, and things interact from there, but this is done differently. In this case, the PC sends most of the initial messages, and waits for replies, but it also collects messages from other ports, such as 502 (Modbus protocol). I hope I am not sounding like I know more than you do, because I'm sure this is not true, but when it comes to the operation of the existing code, I do know that it works as I described. There are probably better ways to do it, however. When I wanted to add a third socket to send a broadcast message, things didn't work, so I started to look further into it. The broadcast would go out each NIC, but the source IP was always the primary NIC's IP. So the new socket was created and bound to each NIC's IP, and port 0. The broadcasts were sent properly, but the replies were never seen by the listener. That's how I got to this point. Sorry for the novel. I'll understand if you want to ignore me now. Thanks again, David.
-
Heh, I fear this is a case where you have too many "unique" details for me to be much help. It seems like you get the drift of what I was saying, but it doesn't directly apply to you. :(