• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • DSO:L1,DSO:L2
  • prodmgmt
  • Reporter: ssubbiah
  • April 04, 2007
  • 0
  • Watchers: 0
  • March 19, 2010


Now with network enabled active/passive, we have communication between L2 - L2. The user already mentions one port in the config for DSO. (Well also mentions JMX port, which can also be avoided atleast for admin console)

We should have a way to open up all other server sockets in L2 on random available ports and be able to communicate it to interested parties over the one known port mentioned in the config.

For example if the user mentions dso port as 9510, that port should be used by all parties interested in connecting to that L2 (like other L2s, L1s, admin client etc.) to find the right port to connect to. This will free the user from specifying a lot of ports in the config and also reduce the chances of “BindException : Address already in use”.


Tim Eck 2007-04-04

using additional ports might not like network/sysadmin people very happy. Random ports seems even more problematic. Other than the effort involved, is there a technical reason we can’t use a single listening port?

Saravanan Subbiah 2007-04-04

Not sure if opening one extra port is going to make someone unhappy, thought tunneling random ports is gonna be a problem. Listing 5 different unique ports in the config is also a pain.

Today tribes uses an unique port and tc-comms uses one for L1 communication. If we use tc-comms for L2-L2 communication,we have complete control over using only one port for these two. Though JmX still needs an extra port anyways. Having the same port for various communication makes some of the protocols more complex than needed. For example when L1 connect to a passive server they need to check the state and close the connection.

Alex Voskoboynik 2007-04-05

I [strongly] agree with Tim. Is there a fundamental reason why L2-L2 communications can’t be achieved through the existing port L2 is already listening on? NOTE: tribes grabbing a port of its own is NOT a fundamental reason. In fact, IMHO, this is just another example of how poorly tribes fit our current needs.

Steve Harris 2007-04-05

Don’t some people who do clustering sometimes run the l2 to l2 comms over a flat out different network interface than the one they talk to clients with? Seems like something we would at least have to support no?

Tim Eck 2007-04-05

for sure using a different (or multiple interfaces) for comms between server machines is something realistic. To that end we definitely are missing a way to do specific interface bindings in our config (the code in TC comm can do it fine). Multiple interface or not, them pesky sysdamin types still might want to keep the set of ports minimal (and non-random)