I've been spending some time on building a server; One of the situations I got in is that I have a streamingsocket (TCP) listener that accepts incoming connections. I know that under water a port will be bound to another port number so new connections can be made on the listening port.
So I tried some functions like getBoundedPort() in order to get the new port number that the server pushed the new connection onto. However, if for instance my listener listens to port 2345, then the bound port will still return 2345. I am not entirely sure why, since if this was really the case, the server couldn't accept new connections due the port being in use.
Generally, I am thinking this problem occurs because the newly bound port number isn't updated internally or the information isn't available.
This situation arises on at least Windows 7 64-bit. I do not know what your experiences are with this.
I'd like to know how the new port number can be retrieved.
Well, as you can see if you step through it, that method calls the OS functions to find out the port number, so there's no danger of it not being updated or anything like that. Maybe Windows just doesn't behave correctly under some conditions?
I know that under water a port will be bound to another port number so new connections can be made on the listening port.
Did you implement that part or did you expect that behaviour? AFAIK a TCP connection will occupy that listening port on the server until the connection is closed. If you want the server to enable many clients to keep open connections, you will need to implement a protocol that tells the client to switch (i.e. open a new connection) to an alternative port, given in the message, which is free at the moment. The initial connection is closed then and free for the next client to sign up.
Otherwise you will have to switch to UDP (leaves you the burden of keeping track of the sequence of arriving packets). But here you can have many connections at a time because the connection is not open but each packet is like an independent connection.
