Multiple Binds on TCP/IP Server Ports – Not Multi Connect

This topic has 9 replies, 4 voices, and was last updated 16 years, 8 months ago by Rob Abbott.

Creator

Topic
March 24, 2008 at 3:26 pm #49923
Bob Richardson
Participant
Greetings,

Folks, we are an AIX5.2 shop running Integrator versions 5.3 Rev3; 5.4.1 Rev2; and, (test only) 5.6.

In running our tests, we have discovered that the Integrator will allow multiple clients to connect to a single TCP/IP server port on the same server. These servers are not configured as multi-connect by the way.

This was discovered while firing up test server connections under 5.6 and not shutting them down first on 5.3 (for example). The host specified was localhost (in this case). The connection requests are not refused by the Cloverleaf Integrator. However, when running hcitcptest (a Perl script) the server ports are locked down and only accept a single bind to a port from a client request via hcitcptest.

Feature or bug?

Prior to migrating to CIS5.3, we were running 3.8.1P and did not have this issue (feature?). To us it appears that in order to implement multi-connect server TCP/IP connections, the integrator had to be softened with regards to allowing multiple clients to connect to a server port within the integrator, that is, not refusing multiple client connect requests to a single server port (no exclusive binds).

What this implies is that we must be extremely careful not to assign the same server port on our box- even if configured as single server only- more than once in the Integrator if we want to maintain control over what client may connect to this server port. Unfortunately, this does not prevent another application from inadvertently connecting to this port anyway. This removes a safety net that we had relied on to protect us from not using the same server port more than once on our box. And in our former guarantees to applications that a port had been dedicated only to their application

So, I am opening this up for discussion in the Forum looking for feedback from you folks about whether this is a feature or bug and needs to be fixed or accepted as status quo.

Enjoy.
Creator

Topic

Viewing 8 reply threads

Author

Replies
- March 24, 2008 at 3:48 pm #64111
  Jim Kosloskey
  Participant
  Bob,
  
  It is my opinion this is a bug.
  
  With standard TCP/IP I would expect to have one and only one connection allowed on a specified port as a server.
  
  If I want multiple client connection as a server I should have to configure it as such using the correct protocol specification.
  
  In my opinion, this needs to be fixed – fast!!!
  
  Jim Kosloskey
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- March 27, 2008 at 3:01 pm #64112
  Bob Richardson
  Participant
  Greetings,
  
  Folks, I must retract my previous complaint about the Cloverleaf Integrator allowing multiple connects to separate single server threads using the same port on an AIX platform. In my statement it was declared that prior to the 5.N versions of the integrator, the Cloverleaf software did not allow a connect/bind to the same port in a connection (box) configured as single server when there was another similarly configured connection using the same port on the same physical platform (same net address). In this scenario we are talking about two or more client/server connections using the same port. (This is not multi-connect, only the old single connect option).
  
  My colleague, Ian Smith, fired up our old 3.8.1P engine (on our task list to remove) and created two separate clients and servers using the same port. The old 3.8.1P engine allowed the connections to be established!!
  
  So, in the face of those results, my original complaint is bogus. In that light I have updated my own “wet ware” database with this new information.
  
  It is my personal mission not to disseminate mis-information to the Cloverleaf community.
  
  Again, the implication is that as developers of interfaces, we must manage and control what ports we assign to what interfaces.
  
  Enjoy.
- March 27, 2008 at 6:41 pm #64113
  Jim Kosloskey
  Participant
  Bob,
  
  Now I am confused (these days that is too frequent 🙂 .
  
  Here is what I did on our 5.2 platform – let me know if this is what you are talking about.
  
  Thread configured as TCP/IP Server – threadA
  
  Thread configured as TCP/IP Client – thread1
  
  Thread configured as TCP/IP Client – thread2
  
  Thread1 and thread2 are pointing to the same Host IP address which is threadA.
  
  Start threadA – in an opening state.
  
  Start thread1 – threadA becomes ‘Up’ and thread1 becomes ‘Up’.
  
  Start thread2 – threadA stays ‘Up’, thread1 stays ‘Up’, thread2 is ‘opening’ and never comes up.
  
  The above is what I expected.
  
  Are you saying in your release of Cloverleaf(R) suing the above architecture, thread2 would also come ‘Up’?
  
  Thanks,
  
  Jim Kosloskey
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- March 27, 2008 at 7:58 pm #64114
  Bob Richardson
  Participant
  Yes, confusion is my friend these days too!
  
  Here is what I am talking about.
  
  Thread configured as TCP/IP Server – threadA port=12345
  
  Thread configured as TCP/IP Server – threadB port=12345
  
  Both servers are on the same Host IP address
  
  Thread configured as TCP/IP Client – thread1
  
  Thread configured as TCP/IP Client – thread2
  
  Start threadA – in opening state
  
  Start threadB – in opening state
  
  Start thread1 – threadA becomes “Up” and thread1 becomes “Up”
  
  ThreadB is in “Opening”
  
  Start thread2 – threadB becomes “Up” and thread2 becomes “Up”
  
  This is what I originally freaked out over but now realize that it is allowed
  
  by the TCP/IP software – at least on our AIX 5.2 platform.
  
  If you do a netstat -an you will “see” separate (what I call) sub-allocations off the main port.
  
  Let me know if this needs more explanation.
  
  Thanks for your response which helped me to illustrate the situation.
  
  Have a great day!
- March 27, 2008 at 8:03 pm #64115
  Jim Kosloskey
  Participant
  Bob,
  
  OK I misunderstood your original post.
  
  Jim Kosloskey
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- March 27, 2008 at 11:30 pm #64116
  Jim Kosloskey
  Participant
  Bob,
  
  I just had to try this for myself.
  
  Everything connected just as you said.
  
  However, there was a Proto Err (Can’t Bind socket on port 99099 Address already in use) raised on the second server thread started.
  
  I tried sending (using the resend) from both clients and the messages looked like they were delivered. Each was delivered to the server to which it connected so there was no cross server contamination.
  
  I did not have the noise level up so I cannot completely determine what occurred under the covers. Something for manana perhaps.
  
  Anyway it looks like Cloverleaf(R) is recognizing an error situation and raising the Proto Error but then dropping the ball.
  
  Again, this looks like a bug to me as it seems to me if there is a Proto Error the thread should go into an Error State and it is not.
  
  If you are communicating with someone from Helathvision about what you see in 5.6 you might want to bring this to their attention. I think this is supposed to Error out and it is not.
  
  Jim Kosloskey
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- March 28, 2008 at 12:32 pm #64117
  Bob Richardson
  Participant
  Jim,
  
  No problem. I will raise this up as an error. Right now I am working on a couple of issues in testing a version of 5.6 Multi-Byte (a feature that will be introduced in the 5.7 version – handling ASCII character sets above the 127 bit range of characters).
  
  Again, thanks for pursuing your research into this “dual server” connectivity “feature”.
  
  Have a great weekend!
- April 3, 2008 at 3:24 pm #64118
  Russ Ross
  Participant
  This bug/feature/behavior goes back as far as I can remember even before 3.8.1.
  
  That is why I made it manditory to assign a unique port number for each server/client across all cloverleaf platforms.
  
  One case of high concern has been when development is done in test cloverleaf environment and then the vendor goes live with that same exact interface.
  
  If they use the same port in this case then the next thing you know you have test messages going to production.
  
  Even if this behavior was modified to only allow one connection, who is to say which client will win the race and connect first.
  
  In other words, we are still left with managing our allocated port numbers.
  
  WARNING!!!
  
  By the way, another real big self inflicted foo-bar will come if you ever use multi-server protocol and have already used ports in the ephimiral range (32k – 64K by default).
  
  We did this during our on-site level 3 training and the host server kept freezing, which was curious since it had never frozen before.
  
  Later on I deduced it was highly likely that using port numbers in the ephimiral range was the bulk of the problem.
  
  The frozen hostserver certainly went away after level 3 training was over and multi-server protocol interfaces were turned off.
  
  In any event, I’m going to disallow assigning ports in the ephimiral range and change the existing one that currently are in violation as I migrate each site to QDX 5.6.
  
  Russ Ross
  RussRoss318@gmail.com
- April 15, 2008 at 7:17 pm #64119
  Rob Abbott
  Keymaster
  This is normal tcp/ip behavior. Here is what you are seeing:
  
  Say you have 2 threads (A and B) configured to listen on port 5000.
  
  Start thread A. It listens on 5000.
  
  Start thread B. It gets “exceeded max retries on bind” trying to listen on port 5000, since A is already listening on that port. If you have “auto reconnect” configured, it will continue to try to listen on that port. I do note that on 5.6 the thread goes into error state although it continues to try to listen.
  
  Connect a client to port 5000. Thread A closes it’s listen after the connection is established. (note: if you have multiserver configured, thread A will not close it’s listen and will continue to listen on the port)
  
  Assuming multiserver is not configured, Thread B is now able to listen on port 5000 since A has closed it’s listen.
  
  Disconnect the client to port 5000. Thread A attempts to listen on 5000 but cannot because thread B has picked up the listen on that port.
  
  Note the above only applies to Unix. I ran some tests on windows, and it appears that multiple processes and or threads can listen on the same port. This works regardless of application (e.g. perl, cloverleaf, etc can all listen on the same port at the same time.). Not sure how Windows decides which server gets the connection when a client tries to connect.
  
  Hope this helps clear things up.
  
  Bottom line I don’t believe this is a Cloverleaf bug but it’s the way that the tcp/ip stack behaves on various operating systems.
  
  Rob Abbott
  Cloverleaf Emeritus
Author

Replies

Viewing 8 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.