|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Change the local port of a server connection after connection is establishedI 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 "Samik R." <sa***@frKKshKll.org> wrote in message This is true.news:12o0j9jd9v69uf6@corp.supernews.com... > [...] > 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. 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 Well, it doesn't. I don't know what the problem is, but a TCP connection is > on the server side to talk to multiple clients in multiple threads. 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 No. Once a connection has been established, the ports used are set in > to change the server side port? 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 Hi Peter,
Thanks a lot for the reply. I have some comments though (inline). On 12/13/2006 1:29 PM, Peter Duniho wrote: Show quote > "Samik R." <sa***@frKKshKll.org> wrote in message Even though the connections are uniquely identified by both endpoints, > news:12o0j9jd9v69uf6@corp.supernews.com... >> [...] >> 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. > 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. >> So my question is, is it possible to modify the socket connection received I actually did some research after posting: basically read the RFC >> 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. > (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 So my solution would be either of (1) making the connecting to be > would be to post a good, concise example of your code that reproduces the > problem and explain exactly what the behavior is. > > Pete > > processed serially (and I can afford that since my file transfers are pretty quick), or (2) follow the design of the ftp server. -Samik "Samik R." <sa***@frKKshKll.org> wrote in message I apologize in advance for my lack of patience. I've been having a tough news:12o0tgvq8rshlf1@corp.supernews.com... > Thanks a lot for the reply. I have some comments though (inline). 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... >> Well, it doesn't. I don't know what the problem is, but a TCP connection It is NOT a problem. I already told you that it is NOT a problem. TCP is >> 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. 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 It is not like that at 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 Then your bug (and you do have a bug) has something to do with transmissions > before sending over the file, the file went through without hanging. 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 The reason for FTP using multiple connections for its design has NOTHING to > (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. 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 Solution #1 is fine if you don't mind that you have a bug in your code. It > processed serially (and I can afford that since my file transfers are > pretty quick), or (2) follow the design of the ftp server. 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
Show quote
"Samik R." <sa***@frKKshKll.org> wrote: Sam,>Hi Peter, > >Thanks a lot for the reply. I have some comments though (inline). > > >On 12/13/2006 1:29 PM, Peter Duniho wrote: >> "Samik R." <sa***@frKKshKll.org> wrote in message >> news:12o0j9jd9v69uf6@corp.supernews.com... >>> [...] >>> 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. > > >>> 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. >> >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 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. "R" <roddy.mu***@ntlworld.com> wrote in message Please don't confuse the issue. There is nothing for Windows to "take care news:VH0gh.2518$1W1.340@newsfe4-win.ntli.net... > [...] > 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) 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  |
|||||||||||||||||||||||
Other interesting topics