First of all, navarro, what behaviour are you looking for? Your first version accepts a single connection from the server and expects to see a sequence of multiple commands being received over it, the second changes to one new socket accept per command, and the last one reverts to behaviour that is almost like the first one except that it has an additional bug (see below). Which one are you looking for?

If you want to receive multiple commands one after another over the same socket, then the client (the side that executes the command) will have to use some kind of scheme to mark the end of the results of that command so that the server knows to stop reading output and send a new command. You expressly do not want to use shutdown for the purpose in this case because you want the socket to stay open bidirectionally for the next command. In this case you should look at how some of the common internet protocols like SMTP do it: schemes like dot stuffing. Any kind of quoting scheme will do if the command output can contain arbitrary data, and if the command output cannot contain arbitrary data, then some marker that consists of impossible data for the command will do. When you receive this marker, you would exit from the read loop (it doesn't matter whether it's read or sysread). Your most recent example does not do this properly: it exits from the while loop (via last) after the first sysread unconditionally (you may as well have not had a loop there). You may or may not have finished collecting all of the output from the command at that point!

If, on the other hand, you want to accept only one command per socket and open a new socket for the next command, then it becomes easier. The client end (which you have not shown code for) should shutdown the socket after it has finished sending the command output and the server will then see an EOF in its read loop. This is analogous to what FTP does with its dedicated data TCP connection for each data transfer.

More importantly than any of this, you should seriously consider how secure all of this is! You have already noticed how you can send multiple commands by seperating them with a semicolon, which I guess means you are passing the commands to a shell on the client side, but even if you were not doing that, your client program appears to be a "please crack me" client. It connects to a server that is not required to authenticated itself, via an unprotected channel, and proceeds to execute any arbitrary command that comes over that socket. Are you sure you want to do this?

In reply to Re^3: Socket hangs by Celada
in thread Socket hangs by navarro

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.