Perl socket communications problem

There are two ports in any socket communication, the server port (which typically shares a large number of sockets on the same port) and the client port, which is different, isn't affected by the firewall, and is the port used (automatically in most cases) by the accept command to finish the TCP handshake that establishes the socket for that TCP "conversation".
BTW, make sure you handle idle sockets well in your server, as it is quite common to have a client drop a socket precipitously (i.e. without notifying the server, thus appearing to just become idle), and this often results in the server running out of socket handles on the server port, since the dead sockets never get released.

Ben Weatherall wrote:

Perl socket communications problem
Joseph,

Thanks for the response. Since all of the perl documentation referred to the "ports" accept used, I didn't understand that these were "virtual" and not something our firewall is going to block. I am not currently a member of the devel list, but this too looks like something I will need to rectify.

-Ben

-----Original Message-----

This is an ideal question for the PLUG-Devel list, I'll answer here for convenience, however.

Ben,
I may be missing something here, as I am not a Perl expert, but usually, when the accept function is called for a TCP socket, the accepted socket continues to communicate on the same port (in your example, on port 4567). There can only be one connection listener on a given port, but there can be multiple active "conversation" sockets (up to 65535, represented in your code by SOMAXCONN) on that same port. TCP handles the multiplexing of the individual sockets using a unique socket identifier sent in the packet structure, and the TCP stack in most systems (including Linux and the BSD's) maintains the server state required to route the data to the various threads handling those sockets as data streams. Unless Perl is doing something I'm completely unaware of, the only port you need to worry about in your firewall would be 4567 using the code listed below (minus the client port part).

That said, It looks like, in the code snippet below, you're trying to initiate an additional socket back to the client using a client port value, is this deliberate? If so, then you just need to do a quick check of the client port, and send an error on the initial socket indicating an acceptable port range. The client software would then need to handle that error by selecting a port within the acceptable range.

==Joseph++