ports issue

Hi,

I just ran into an issue with ports. I am not sure if this is a unix-related question or a gemstone configuration issue:

I have configured our netldi to operate in the presence of a firewall [1]
This means port 50378 gets used by netldi and it just occurred that a linked topaz session was now using the same port. This is the output of 'lsof' command regarding port 50378:

COMMAND     PID  USER   FD   TYPE   DEVICE SIZE NODE NAME
topaz      2673 sites    6u  IPv4 55698169       TCP localhost:50378->localhost:51688 (ESTABLISHED)
shrpcmoni 31372 sites   14u  IPv4 55698170       TCP localhost:51688->localhost:50378 (ESTABLISHED)

This lead to a problem that we could not connect from gemtools because netldi was unable to use the port. From the gemobject.log:

Unable to create well-known socket for client program.
bind(4,port=50378) failed with errno=98,EADDRINUSE, Address is already in use

Now my question: is this 'normal'? We are using linked topaz sessions only and the process was a FastCGI gem. And if yes how can I prevent it from happening?

best regards,
Johan

[1] http://forum.world.st/Remote-support-on-wan-for-Gemstone-server-tt4348677.html#a4425381

Johan,

It turns out that 32000 is the starting point for random port generation, so the shrpcmonitor is within it's "rights" to use 50378. To avoid this problem in the future, you should use a listening port number that is less than 32000.

I know that we've recommended using port numbers like 50378 for the listening ports in the past, but we should have recommended using a port number less than 32000.

Dale

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, March 20, 2013 3:58:51 AM
| Subject: [GS/SS Beta] ports issue
|
| Hi,
|
| I just ran into an issue with ports. I am not sure if this is a unix-related
| question or a gemstone configuration issue:
|
| I have configured our netldi to operate in the presence of a firewall [1]
| This means port 50378 gets used by netldi and it just occurred that a linked
| topaz session was now using the same port. This is the output of 'lsof'
| command regarding port 50378:
|
| COMMAND     PID  USER   FD   TYPE   DEVICE SIZE NODE NAME
| topaz      2673 sites    6u  IPv4 55698169       TCP
| localhost:50378->localhost:51688 (ESTABLISHED)
| shrpcmoni 31372 sites   14u  IPv4 55698170       TCP
| localhost:51688->localhost:50378 (ESTABLISHED)
|
| This lead to a problem that we could not connect from gemtools because netldi
| was unable to use the port. From the gemobject.log:
|
| Unable to create well-known socket for client program.
| bind(4,port=50378) failed with errno=98,EADDRINUSE, Address is already in use
|
| Now my question: is this 'normal'? We are using linked topaz sessions only
| and the process was a FastCGI gem. And if yes how can I prevent it from
| happening?
|
| best regards,
| Johan
|
| [1]
| http://forum.world.st/Remote-support-on-wan-for-Gemstone-server-tt4348677.html#a4425381

On 03/20/2013 10:23 AM, Dale Henrichs wrote:
> Johan,
>
> It turns out that 32000 is the starting point for random port generation, so the shrpcmonitor is within it's "rights" to use 50378. To avoid this problem in the future, you should use a listening port number that is less than 32000.
>
> I know that we've recommended using port numbers like 50378 for the listening ports in the past, but we should have recommended using a port number less than 32000.

Assuming you're using Linux:

To find the ephemeral port range on your Linux installation,

  cat /proc/sys/net/ipv4/ip_local_port_range

A common range for Linux is

  32768   61000

So, as Dale says, below 32768 should prevent these collisions, and above
61000 but below 65536 should also work.

However, IANA registered ports go up to 49151, so if you go below 32768
it's best to check and use one that's unassigned. However, what's
unassigned today might become assigned tomorrow, so you might want to go
above 61000, but I haven't actually tried that.

Regards,

-Martin

Thanks for the explanation guys.

Perhaps adapting to these other port ranges is entering unknown territory. Since this was the first time ever that it occurred, and I now know it's to be expected, I guess it's not a big deal to leave it as it is.

On 20 Mar 2013, at 23:26, Martin McClure <[hidden email]> wrote: