Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #1043 > unrolled thread

Unix Domain Socket

Back to article view | Back to comp.unix.programmer

Contents

  Unix Domain Socket noneinwind <warmyouth@gmail.com> - 2011-08-01 06:50 -0700
    Re: Unix Domain Socket Volker Birk <bumens@dingens.org> - 2011-08-01 15:14 +0000
      Re: Unix Domain Socket noneinwind <warmyouth@gmail.com> - 2011-08-02 05:44 -0700
        Re: Unix Domain Socket Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-02 14:21 +0100
      Re: Unix Domain Socket wy <warmyouth@gmail.com> - 2011-08-03 19:35 -0700
        Re: Unix Domain Socket Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-04 12:15 +0100
    Re: Unix Domain Socket Nobody <nobody@nowhere.com> - 2011-08-02 03:52 +0100
      Re: Unix Domain Socket Nicolas George <nicolas$george@salle-s.org> - 2011-08-02 08:58 +0000
      Re: Unix Domain Socket Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-02 12:21 +0100

#1043 — Unix Domain Socket

Hello, I've seen an example on the Internet about Unix Domain Socket.
It says, "Different from network socket program, Unix Domain Socket
client generally calls bind explicitly, rather than use address
assigned automaticlly by the system. Binding to a specified socekt
file containing client's pid, we can distinguish clients from each
other."
And following is the following:

#include <stdio.h>
#include <stddef.h>
#include <sys/stat.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <errno.h>

#define CLI_PATH    "/var/tmp/"      /* +5 for pid = 14 chars */

/*
 * Create a client endpoint and connect to a server.
 * Returns fd if all OK, <0 on error.
 */
int cli_conn(const char *name)
{
	int                fd, len, err, rval;
	struct sockaddr_un un;

	/* create a UNIX domain stream socket */
	if ((fd = socket(AF_UNIX, SOCK_STREAM, 0)) < 0)
		return(-1);

	/* fill socket address structure with our address */
	memset(&un, 0, sizeof(un));
	un.sun_family = AF_UNIX;
	sprintf(un.sun_path, "%s%05d", CLI_PATH, getpid());
	len = offsetof(struct sockaddr_un, sun_path) + strlen(un.sun_path);

	unlink(un.sun_path);        /* in case it already exists */
	if (bind(fd, (struct sockaddr *)&un, len) < 0) {
		rval = -2;
		goto errout;
	}

	/* fill socket address structure with server's address */
	memset(&un, 0, sizeof(un));
	un.sun_family = AF_UNIX;
	strcpy(un.sun_path, name);
	len = offsetof(struct sockaddr_un, sun_path) + strlen(name);
	if (connect(fd, (struct sockaddr *)&un, len) < 0) {
		rval = -4;
		goto errout;
	}
	return(fd);

errout:
	err = errno;
	close(fd);
	errno = err;
	return(rval);
}



Here's what I do not understand:
In this example, the struct "un" is cleared twice.
So, is "un" of no use after "bind" is called successfully?

[toc] | [next] | [standalone]

#1044

noneinwind <warmyouth@gmail.com> wrote:
> In this example, the struct "un" is cleared twice.
> So, is "un" of no use after "bind" is called successfully?

In this simple example "un" seems to be used twice, for two different
addresses. It's just reused. The programmer could have used two structs
instead of one.

And yes, after bind() it's not of great use any more in this example
code.

Yours,
VB.
-- 
Wenn Du für eine Leistung nichts bezahlst,
bist Du nicht der Kunde, sondern die Ware.

[toc] | [prev] | [next] | [standalone]

#1049

On Aug 1, 11:14 pm, Volker Birk <bum...@dingens.org> wrote:
> In this simple example "un" seems to be used twice, for two different
> addresses. It's just reused. The programmer could have used two structs
> instead of one.
>
> And yes, after bind() it's not of great use any more in this example
> code.
>
> Wenn Du für eine Leistung nichts bezahlst,
> bist Du nicht der Kunde, sondern die Ware.

and why it ends with
        err = errno;
        close(fd);
        errno = err;
?
I saw somewhere about the errno, but paid not enough attention to it.
Does it mean close(fd) changes "errno", and on the other hand we need
the previous "errno" out of this function?

[toc] | [prev] | [next] | [standalone]

#1051

noneinwind <warmyouth@gmail.com> writes:
<snip>
> and why it ends with
>         err = errno;
>         close(fd);
>         errno = err;
> ?
> I saw somewhere about the errno, but paid not enough attention to it.
> Does it mean close(fd) changes "errno", and on the other hand we need
> the previous "errno" out of this function?

Yes, that is presumably the intent.  close can change errno and the
author supposes that the caller will want the value or errno from the
bind or connect call rather than from the close that was only done
because one or other of these calls failed.  By returning -1, -2 or -4
depending on which of the socket, bind or connect failed the caller can
interpret errno correctly.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#1055

I do not konw why the reply i posted yesterday has not been appeared.
So...Should I ask a question?

why this example ends with:

err = errno;
close(fd);
errno = err;

Does it mean that function close(fd) has effect on errno, so err stores its value and back later?
And if I do not back up the real value of errno, nothing will happen, right?

[toc] | [prev] | [next] | [standalone]

#1057

wy <warmyouth@gmail.com> writes:
> I do not konw why the reply i posted yesterday has not been appeared.
> So...Should I ask a question?
>
> why this example ends with:
>
> err = errno;
> close(fd);
> errno = err;
>
> Does it mean that function close(fd) has effect on errno, so err stores its value and back later?
> And if I do not back up the real value of errno, nothing will
> happen, right?

Actually, it has appeared and was answered. Here is the answer again:
The value of errno may be changed in the course of executing any
routine that's documented as using it to return error codes, even if
the routine itself didn't fail (although this is also possible). In
this case, the caller should see the errno value set by the routine
whose failure lead to entering the 'exit with error codepath' and not
some other, related or unrelated errno value set by a routine executed
'on the way out'. Because of this, the value is saved to a local
variable and then restored.

[toc] | [prev] | [next] | [standalone]

#1045

On Mon, 01 Aug 2011 06:50:39 -0700, noneinwind wrote:

> Hello, I've seen an example on the Internet about Unix Domain Socket.
> It says, "Different from network socket program, Unix Domain Socket
> client generally calls bind explicitly, rather than use address
> assigned automaticlly by the system. Binding to a specified socekt
> file containing client's pid, we can distinguish clients from each
> other."

I don't know where you read that, but I wouldn't put much faith in it.

Unix-domain client sockets are normally unnamed; there is usually no
reason for the client end to have a name.

Unlike TCP/IP sockets, where each end always has a port number, and an
ephemeral port is allocated by the OS if none is chosen explicitly,
Unix-domain sockets don't have to be named. E.g. with socketpair(), both
sockets are unnamed; as they are connected from the outset, there is no
need for names.

[toc] | [prev] | [next] | [standalone]

#1046

Nobody , dans le message <pan.2011.08.02.02.52.20.69000@nowhere.com>, a
 écrit :
> Unix-domain client sockets are normally unnamed; there is usually no
> reason for the client end to have a name.

For SOCK_DGRAM sockets not created by socketpair, I believe the client needs
a name to be able to get responses.

[toc] | [prev] | [next] | [standalone]

#1047

Nobody <nobody@nowhere.com> writes:
> On Mon, 01 Aug 2011 06:50:39 -0700, noneinwind wrote:
>
>> Hello, I've seen an example on the Internet about Unix Domain Socket.
>> It says, "Different from network socket program, Unix Domain Socket
>> client generally calls bind explicitly, rather than use address
>> assigned automaticlly by the system. Binding to a specified socekt
>> file containing client's pid, we can distinguish clients from each
>> other."
>
> I don't know where you read that, but I wouldn't put much faith in it.
>
> Unix-domain client sockets are normally unnamed; there is usually no
> reason for the client end to have a name.
>
> Unlike TCP/IP sockets, where each end always has a port number, and an
> ephemeral port is allocated by the OS if none is chosen explicitly,
> Unix-domain sockets don't have to be named. E.g. with socketpair(), both
> sockets are unnamed; as they are connected from the outset, there is no
> need for names.

AF_UNIX datagram sockets are different from AF_INET datagram sockets
in that (at least on Linux) no usuable 'default address' exists:
Provided that such a socket is supposed to receive anything, an
address needs to be bound to it.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.unix.programmer

csiph-web