UNIX datagram sockets

X

Xho Jingleheimerschmidt

John said:
I thought the code made it clear. What don't you understand about it?
Why are you unlinking them? What point does $node serve in the client?

Xho
 
J

John Kelly

Why are you unlinking them?

IO::Socket::UNIX->new does a bind() for you, automatically. If the name
already exists in the filesystem, bind() will fail.

What point does $node serve in the client?

This can be confusing, and that's why I posted.

To achieve two way communication over UNIX datagram sockets, both server
and client must bind to a socket. But NOT THE SAME ONE!

The server binds to the server socket, and the client binds to the
client socket. Notice that two different file names are required.
That's what Local => $node is for. They each bind to their own "Local"
socket.

Then the server sits there and waits for incoming connections on his
"Local" /tmp/server.sock.

Now say the client wants to talk. He's already bound his own "Local"
/tmp/client1.sock. But he also has to specify what "Peer" he wants to
talk to, in this case the server, which resides at /tmp/server.sock.

When the server gets a packet from the client, he knows where it came
from, because the client did a bind() to his own "Local" client socket
before sending. If the client omits the bind() step, the client can
send to the server, but the packet will not carry a peer address, and
the server won't know where it came from.
 
J

John Kelly

It concerns me because people who engage in trollish behavior shouldn't
be accusing others of trolling. But I certainly won't carry on the
debate any further. (Or perhaps "take the bait" is more apt.)

Some people think anyone who says anything they don't like, is a troll.

I started this thread with useful material, but you bring up defamatory
posts from other ngs, completely unrelated to the topic.

See wikipedia for a definition of trolling.
 
J

John Kelly

This can be confusing, and that's why I posted.

Or at least one reason. Another is:

UNIX datagram sockets are not widely understood. The books that discuss
them usually leave them last, with little supporting material to explain
why they are so useful. Books tend to focus on stream sockets.

But for many applications of intra-server communications, stream sockets
are not needed, and are overkill. With stream sockets, you have to keep
track of all the connections, which means more work for the programmer.

Datagram sockets are easier because there are no connections. You just
use bind() to establish each node's address, and then, any node can talk
to any other node, at random. Because the kernel handles buffering for
you, UNIX datagram sockets are always reliable, and datagrams are always
delivered in order. So you never lose any packets.

UNIX datagram sockets are underrated. Once you understand the basic
code required, they're easy, and you can be a socket programmer without
a hard learning curve.

Perl helps too. You can throw some Perl scripts together and presto,
you have a socket application.

What's the point of tools anyway, if not to make work easier? You don't
need to be an expert to make effective use of tools.
 
R

RedGrittyBrick

[Much]

....

Just my ¤0.02 worth:

If I wanted to write an essay about some aspect of Perl usage, I would
open an account somewhere like blogger.com.

If I wanted to fill a gap in the Perl docs or FAQ, I would draft a
revised FAQ entry or revised doc section and submit it to the relevant
maintainers. I'd expect to have to rewrite it once or twice if asked. I
would set my expectations minimally.

If I wanted to make some sort of helpful announcement in CLPM I'd say so
in the subject, or at least at the top of the posting. (Obviously there
is a certain amount of hindsight here, but I like to think I would
probably have done this anyway).

I would try to remember that gifts should not be conditional on the
recipients' gratitude or even appreciation.

If I was tempted to engage in, or continue, an acrimonious argument, I'd
go for a walk in the park, until the temptation faded away†.

As may be evident, in my case the above are somewhat aspirational.

As I said, just my ¤0.02 worth. Your Mileage May Vary.
 
J

John Kelly

If I wanted to write an essay about some aspect of Perl usage, I would
open an account somewhere like blogger.com.

If I wanted to fill a gap in the Perl docs or FAQ, I would draft a
revised FAQ entry or revised doc section and submit it to the relevant
maintainers. I'd expect to have to rewrite it once or twice if asked. I
would set my expectations minimally.

If I wanted to make some sort of helpful announcement in CLPM I'd say so
in the subject, or at least at the top of the posting. (Obviously there
is a certain amount of hindsight here, but I like to think I would
probably have done this anyway).

I would try to remember that gifts should not be conditional on the
recipients' gratitude or even appreciation.

If I was tempted to engage in, or continue, an acrimonious argument, I'd
go for a walk in the park, until the temptation faded away†.

As may be evident, in my case the above are somewhat aspirational.

Oh I agree that's good advice. But I don't always have time to think
that far ahead. So I just throw it out there and let it fall where it
may.

If anyone wants to take my posts and make an FAQ or whatever, go for it.
I don't do this for personal accolades or status. I just enjoy talking
up good ideas.
 
P

Peter J. Holzer

Stein has an example of UNIX datagram sockets in his Networking book,
but it includes other ideas that, to me, made it hard to see the forest
for the trees. So I distilled it down to the bare essential elements
related to socket setup.

I thought there should be lots of examples floating around on the web,
but they seem hard to find (maybe my Google-Fu is weak, or maybe nobody
uses Unix datagram sockets (I know I don't)). So I think your example is
useful.

Please ignore bad practices in this code, it's only intended to show how
to set up the datagram sockets, which to me, seemed mysterious without a
simple example.


--- CLIENT ---

#!/usr/bin/perl

use strict;
use warnings;
use IO::Socket::UNIX;

my $peer = '/tmp/server.sock';
my $node = '/tmp/client1.sock';
unlink $node;

my $sock = IO::Socket::UNIX->new (
Local => $node,
Peer => $peer,
Type => SOCK_DGRAM
) or die "$!";

The usage of Local here does seem a bit mysterious. But since
the DGRAM service is connectionless it's clear that a different socket
is needed to receive the replies. If you had added a few comments
explaining stuff like that it would have been even more useful.

hp
 
J

John Kelly

The usage of Local here does seem a bit mysterious. But since
the DGRAM service is connectionless it's clear that a different socket
is needed to receive the replies.

It's clear once you see the big picture. But when you're learning, and
swimming in details, it may not be so obvious.

If you had added a few comments explaining stuff like that it would
have been even more useful.

Agreed. I eventually got around to that, in subsequent posts. Maybe
that's not such a bad thing. The longer a post is, the fewer people who
will read it.
 
M

Mart van de Wege

Peter J. Holzer said:
I thought there should be lots of examples floating around on the web,
but they seem hard to find (maybe my Google-Fu is weak, or maybe nobody
uses Unix datagram sockets (I know I don't)). So I think your example is
useful.

Try looking for 'Unix Domain Sockets'. The first hit of that + 'Perl'
gives an excerpt from the Perl Cookbook.

Mart
 
J

John Kelly

Try looking for 'Unix Domain Sockets'. The first hit of that + 'Perl'
gives an excerpt from the Perl Cookbook.

Too bad that example won't work. Can you google any that do?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top