As jepri said so clearly, sockets are bidirectional. So, using two for each client is really a waste unless you have a real good reason for it. Note: one for sending and one for receiving is not a good reason. I can only think of one common example where such a scheme is used. FTP uses separate control and data connections. Then again, FTP pretty much sucks as a protocol.

Also as jepri said, you don't need to instruct your clients to use all sorts of different ports. A server can handle multiple connections to a single port. Really, you can think of the port as simply part of the address for the server. Its a useful abstraction that permits many different servers to run on a single box.

A web server for example generally runs on port 80 and can handle multiple clients at once without telling them to come back and meet it on another port. A web server might not be an obvious example because the requests are so short that you might think it handles them sequentially but that's not the case. Either take my word for it or consider telnet servers, IRC servers, MUDs, sshd, etc, etc, etc. instead.

So, finally, lets figure out what you should be doing. You want to have a server listening on $port. You want clients to connect to $port. You want the server to then "hold a conversation" with the client.

If that's all you want to do, then you should probably have your server fork in which case the parent will answer more incoming connections to $port and the child will handle the client's request. In this scenario, the server is never really "managing" more than one client connection at a time.

On the other hand, if there has to be some shared state between clients (as is the case in IRC or MUDs) then you'll need to handle multiple client connections in the server. Please notice the language I am using. You don't manage multiple ports, you manage multiple connections. Moving on, if this is the case, you'll need to use select() or IO::Select. The general idea is that you loop and occassionaly check to see if your clients sent data, if they have you read the data, and if you can, you do something with it. If you have data to send to the client, you just do so. For various reasons, this tends to be a lot stickier to code than a forking server. The good news is you probably don't really need to do it. Forking servers are best for many applications.

Now the real question... What do you want your server to actually do? Without knowing this, we can't very well recommend how to do it.

-sauoq
"My two cents aren't worth a dime.";

In reply to Re: Networking with Perl by sauoq
in thread Networking with Perl by gri6507

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.