Hi,

As aukjan said, take a look at IO::Socket::INET.

A small example:

use strict;
use warnings;

use IO::Socket::INET;
use Socket qw(:DEFAULT :crlf);

$|++;

my $hostname = 'localhost';
my $port = 2001;

my $sock = IO::Socket::INET->new(PeerAddr => $hostname,
                   PeerPort => $port,
                   Proto    => 'tcp')
        or die "Can't connect: $!";

$sock->autoflush(1);

print $sock "Hello, World!$CRLF";  # Using $CRLF is more portable

close $sock;
[download]

Hope it give you an idea

Regards,

Thank you! Indeed reading the documentation for IO::Socket I noticed that it gives an example with IO::Socket::INET.

The fact that you suggest yourself that $CRLF is more portable is one of the reasons I asked in the first place, because I suspected that for a complete newbie there may have been some quirks that more experienced users would have been possibly more familiar with.

You probably want to start at perlipc and check the examples in there.

/J\

Indeed this is a valuable suggestion that like most obvious things could have occurred to me in the first place, but for some reason just didn't! Actually perlipc helped me a lot when learning about named pipes and signals...

Depending on what it is that you want to do, you might consider using a higher-level library than just basic sockets. For instance, a while back I needed to put together a client/server networking module for getting backups moved from one system to another across a network. There are a number of ways I could have done it, but I ended up combining HTTP::Daemon on the one end with system('wget', @args) on the other. In retrospect, I could just as easily have used WWW::Mechanize instead of wget and/or Net::Server in lieu of HTTP::Daemon. For that matter, the one system has Apache running anyhow, so I could have used WWW::Mechanize on the one end and plain old CGI on the other. If what you're doing could use features you don't feel like implementing, such as the ability for more than one client to connect at a time, going with one of these routes is worthwhile. After all, who wants to write forking code when you don't have to?

On the other hand, if your goal is learning about networking, then writing a basic client/server socket setup is quite worthwhile. My first experiment in this was a Hello, World server -- the client would connect and say "Hello, Server World", and the server answered back, "Hello, Client World". The downside of this kind of lowlevel approach is that the server for my Hello, World thing is over forty lines, and all it does is listen for one client connection at a time, check if they say a certain thing, say a certain thing back, log it, and close the socket. That's not very much to do in forty lines of Perl.

Thank you for the extensive answer. The goal is not much more complex than the explicit description given in the original post. Of course I'm trying to make this into a chance for learning about networking.

Certainly I'm aware of the LWP family of modules, and I've heard but not really used (yet) WWW::Mechanize - in any case I'm not about to reimplement them!!

Hi,

I recommend you this book, is not about Perl, it's C, but anyway the concepts can be ported, and gives you an idea on low level, so you can understand well the IO::Socket, and network programming in general.

Also take a look at POE, you can do really nice things with it.

Regards,

|fire| at irc

What have you tried sofar?? Please show some code.. I would use IO::Socket::INET

If you check my past posts, I think you'll find I'm not one who routinely asks for do-it-for-me solutions. And I must admit I give similar answers when one does, but in this case since I do know very little about networking in general, let alone in Perl, I would have been glad to see some minimal code as a primer - which is what I explicitly asked for. Of course this won't prevent me from reading further
• tutorials,
• examples,
• docs,
and try something myself, then come back here in case I find any actual difficulty. Something along the lines of what fmerges supplied at Re: Very basic socket question is perfect.

point taken, Usually I like to see some code, and comment to that. I usually assume that people try to write something and then if they can't figure it out, post it here. Then it is easier to see where the 'rub' lies...
In the future I will check more closely to see who asks the question and what the background of a certain question is. Hope that you can create a solution with the primer from fmerges.