Change the local port of a server connection after connection isestablished

[Samik R.]

Hello,

I am trying to write a multi-threaded server app, where the server
listens at a particular port and creates a new thread each time a client
connection has been received. The new thread then handles some
handshaking and some file transfer.

The problem is as follows: if 2 or more clients connect at the same time
(which they do), each gets their own thread. The LocalEndPoint (IP and
Port) of the sockets are the same in each of the thread, so one thread
hangs on the file transfer while another one succeeds. I think the
problem has got something to do with using the same local port on the
server side to talk to multiple clients in multiple threads.

So my question is, is it possible to modify the socket connection
received to change the server side port? How to design this? How do a
typical FTP server does this?

Thanks.
-Samik

 

[Peter Duniho]

[...]
The problem is as follows: if 2 or more clients connect at the same time
(which they do), each gets their own thread. The LocalEndPoint (IP and
Port) of the sockets are the same in each of the thread,

This is true.

so one thread hangs on the file transfer while another one succeeds.

It may be true that one of your threads hangs, but if it is, it's not
because the LocalEndPoint is the same as that used by another thread.

I think the problem has got something to do with using the same local port
on the server side to talk to multiple clients in multiple threads.

Well, it doesn't. I don't know what the problem is, but a TCP connection is
uniquely identified by *both* endpoints. Every connection returned from the
listening port will have the same port number and IP address as that
listening port, and this isn't a problem because each of those connections
also has a unique remote endpoint.

So my question is, is it possible to modify the socket connection received
to change the server side port?

No. Once a connection has been established, the ports used are set in
stone. You cannot change them on the fly. However, this is not a problem
at all.

How to design this? How do a typical FTP server does this?

A typical FTP server works the same way any other TCP-aware application
would. Since each connection *is* unique, due to the remote endpoint being
unique, there is no conflict between connections, even though the local
endpoints are identical.

So, you are barking up the wrong tree. If you want help, the best thing
would be to post a good, concise example of your code that reproduces the
problem and explain exactly what the behavior is.

Pete

 

[Samik R.]

Hi Peter,

Thanks a lot for the reply. I have some comments though (inline).

[...]
The problem is as follows: if 2 or more clients connect at the same time
(which they do), each gets their own thread. The LocalEndPoint (IP and
Port) of the sockets are the same in each of the thread,

This is true.

so one thread hangs on the file transfer while another one succeeds.

It may be true that one of your threads hangs, but if it is, it's not
because the LocalEndPoint is the same as that used by another thread.

I think the problem has got something to do with using the same local port
on the server side to talk to multiple clients in multiple threads.

Well, it doesn't. I don't know what the problem is, but a TCP connection is
uniquely identified by *both* endpoints. Every connection returned from the
listening port will have the same port number and IP address as that
listening port, and this isn't a problem because each of those connections
also has a unique remote endpoint.

Even though the connections are uniquely identified by both endpoints,
it might still be the problem. Since two or more sockets would share the
same local endpoint, if they all try to send data at the same time, it
is like 2 or more people trying to enter through a single window at the
same time. I am pretty sure about this, because when I introduced a
random delay before sending over the file, the file went through without
hanging.

No. Once a connection has been established, the ports used are set in
stone. You cannot change them on the fly. However, this is not a problem
at all.


A typical FTP server works the same way any other TCP-aware application
would. Since each connection *is* unique, due to the remote endpoint being
unique, there is no conflict between connections, even though the local
endpoints are identical.

I actually did some research after posting: basically read the RFC
(http://www.faqs.org/rfcs/rfc959.html). Actually, they have a different
design for this problem. The server has two components: (1) A protocol
interpreter (PI), which reads a line and replies accordingly, always
waiting for new connections at the same port, and (2) Data Transfer
Process, which exclusively takes care of file transfers. This transfer
happens at different port than the one where PI listens, which is
specified by the server at runtime.

So, you are barking up the wrong tree. If you want help, the best thing
would be to post a good, concise example of your code that reproduces the
problem and explain exactly what the behavior is.

Pete

So my solution would be either of (1) making the connecting to be
processed serially (and I can afford that since my file transfers are
pretty quick), or (2) follow the design of the ftp server.

-Samik

 

[Peter Duniho]

Thanks a lot for the reply. I have some comments though (inline).

I apologize in advance for my lack of patience. I've been having a tough
week or so, and I'm not known for my great patience in the first place. So,
keep in mind that if you continue to insist on refusing to believe what you
are told, I won't have the patience to keep trying to help you.

That said, my comments to your comments...

Even though the connections are uniquely identified by both endpoints, it
might still be the problem.

It is NOT a problem. I already told you that it is NOT a problem. TCP is
quite commonly used by a wide variety of servers that always use the same
local endpoint, as derived from the listening socket, with connections
uniquely determined by the local/remote endpoint combination.

Since two or more sockets would share the same local endpoint, if they all
try to send data at the same time, it is like 2 or more people trying to
enter through a single window at the same time.

It is not like that at all.

I am pretty sure about this, because when I introduced a random delay
before sending over the file, the file went through without hanging.

Then your bug (and you do have a bug) has something to do with transmissions
attempting to occur at the same time. That doesn't mean that there is any
problem with multiple connections having the same local endpoint.

You can be "pretty sure" all you like, it doesn't change the fact that TCP
works just fine with a single listening socket, multiple connections
accepted from that listening socket all with the same local endpoint. If
you have problems, it's due to some other reason.

I actually did some research after posting: basically read the RFC
(http://www.faqs.org/rfcs/rfc959.html). Actually, they have a different
design for this problem. The server has two components: (1) A protocol
interpreter (PI), which reads a line and replies accordingly, always
waiting for new connections at the same port, and (2) Data Transfer
Process, which exclusively takes care of file transfers. This transfer
happens at different port than the one where PI listens, which is
specified by the server at runtime.

The reason for FTP using multiple connections for its design has NOTHING to
do with any issues related to identical local endpoints. An FTP server can
host multiple clients on the same port (whether that is the interpreter or
transfer port) without any trouble at all, and this happens quite commonly.

So my solution would be either of (1) making the connecting to be
processed serially (and I can afford that since my file transfers are
pretty quick), or (2) follow the design of the ftp server.

Solution #1 is fine if you don't mind that you have a bug in your code. It
probably will successfully avoid the bug, but you won't have fixed the bug,
and it's possible the bug is more serious than just preventing simultaneous
access.

Solution #2 is just silly. Since the reason that FTP uses multiple
connections has nothing to do with the question of simultaneous transfers,
if following FTP's design causes your problem to go away then all you've
done is hide the bug (just as you might with Solution #1). More likely,
following FTP's design won't have any effect on your bug at all.

It's not clear to me why you refuse to believe me when I tell you that the
"same local endpoint" issue is a complete non-issue. But as long as you
persist in your dedication to that red herring, you are not going to fix
your real problem. You might hide it for a while, but as with all bugs, the
underlying actual bug is sure to show up in some form again later, if you
fail to fix it.

Good luck with that.

Pete

 

[R]

Hi Peter,

Thanks a lot for the reply. I have some comments though (inline).

[...]
The problem is as follows: if 2 or more clients connect at the same time
(which they do), each gets their own thread. The LocalEndPoint (IP and
Port) of the sockets are the same in each of the thread,

This is true.

so one thread hangs on the file transfer while another one succeeds.

It may be true that one of your threads hangs, but if it is, it's not
because the LocalEndPoint is the same as that used by another thread.

I think the problem has got something to do with using the same local port
on the server side to talk to multiple clients in multiple threads.

Well, it doesn't. I don't know what the problem is, but a TCP connection is
uniquely identified by *both* endpoints. Every connection returned from the
listening port will have the same port number and IP address as that
listening port, and this isn't a problem because each of those connections
also has a unique remote endpoint.

Even though the connections are uniquely identified by both endpoints,
it might still be the problem. Since two or more sockets would share the
same local endpoint, if they all try to send data at the same time, it
is like 2 or more people trying to enter through a single window at the
same time. I am pretty sure about this, because when I introduced a
random delay before sending over the file, the file went through without
hanging.

No. Once a connection has been established, the ports used are set in
stone. You cannot change them on the fly. However, this is not a problem
at all.


A typical FTP server works the same way any other TCP-aware application
would. Since each connection *is* unique, due to the remote endpoint being
unique, there is no conflict between connections, even though the local
endpoints are identical.

I actually did some research after posting: basically read the RFC
(http://www.faqs.org/rfcs/rfc959.html). Actually, they have a different
design for this problem. The server has two components: (1) A protocol
interpreter (PI), which reads a line and replies accordingly, always
waiting for new connections at the same port, and (2) Data Transfer
Process, which exclusively takes care of file transfers. This transfer
happens at different port than the one where PI listens, which is
specified by the server at runtime.

So, you are barking up the wrong tree. If you want help, the best thing
would be to post a good, concise example of your code that reproduces the
problem and explain exactly what the behavior is.

Pete

So my solution would be either of (1) making the connecting to be
processed serially (and I can afford that since my file transfers are
pretty quick), or (2) follow the design of the ftp server.

-Samik

Sam,

I am not sure how many clients you have in your system, but I had to build a network
application recently which had to manage an unknown number of clients (several
hundred) at the same time and be able to reliably circulate messages to them as well.

Building your own reliable FTP module from scratch in any language, with
fast messaging capability could be a lot of unnecessary work for you, but as I say, I'm
not aware of how many clients you have.

If you have even just a couple of clients, e.g 9, use an existing FTP server in your
solution, where each client firstly connects to a custom, lightweight server, namely the
one which you build. How your server represents a client connection internally is
completely up to you.

You could represent a client connection as a record entry in a database or as an entry
in a hash table for better performance, and this will also give you the flexibility to
organise your client connections into logical "groups", because your clients may be in
different offices, departments etc, thus subsets of the connected clients can be
commanded remotely. (Hope I made sense there.) Sorry for too much detail.

As you have correctly stated, your lightweight server needs to listen for client
connections on one port, however the implementation of sockets for microsoft windows
takes care of assigning the ports that your server communicates with each of its clients
on. (Hope I made sense there)

When the client(s) need to FTP simply have your lightweight server pass the clients a
small (tiny) message, such as a string containing the filename and path of where to
download from on the remote filesystem. You can put the FTP server IP, login name
and password, in an ini file, at the client site. This is just my suggestion though.

Cheers.

 

[Peter Duniho]

[...]
As you have correctly stated, your lightweight server needs to
listen for client connections on one port, however the implementation
of sockets for microsoft windows takes care of assigning the ports
that your server communicates with each of its clients on. (Hope
I made sense there)

Please don't confuse the issue. There is nothing for Windows to "take care
of" with respect to assigning server ports for connections to clients. The
local server port for each client connection is identical to the port used
for the listening socket. This is standard TCP behavior.

IMHO, the rest of your advice is probably also overly-complicated and
possibly inappropriate, but for sure the above is just plain wrong.

Pete