Re: Perl socket communications problem

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
Delete this message
Reply to this message
Author: Joseph Sinclair
Date:  
To: plug-discuss
Subject: Re: 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:

> 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++

>