unix domain socket with shared memory ?

unix domain socket with shared memory ?

[Ralf Habacker]

Hi all,

cfg has told me about the current process of cygwin daemon implementation with ipc support.

I initial have heard last year, that this work would be started, but because of so much other work I have lost the
contact to the ongoing process.

Now I was looking into the ongoing work and it seems to me in a mostly read state, isn't it. I like to say: Great
work to all who have worked on it. :-)

The reason why I'm writing this is that I have recognized some performance issues with unix domain sockets, which
are used very much by kde and currently I'm looking for a way to speed this up. I have seen that unix domain
sockets are eumlated through tcp connections and this seems to me the reason, why unix domain sockets are only half
as fast as pure tcp sockets. The benchmark results are located at http://cygwin.com/ml/cygwin/2002-01/msg01719.html

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
BRAMSCHE  CYGWIN_NT-5.0 130. 17.5 40.0  337.0  477.7  145.2  133.8 476. 200.9
BRAMSCHE   Linux 2.2.18 343. 235. 64.4  177.7  238.5   71.5   61.4 238.  75.3
                             ^^^^

Some guys may say, unix domain sockets are not implemented through tcp connection, but I'm relative sure, that this
is true:

KDE's dcopserver uses ICE which uses unix domain sockets. After starting this serverapp a diff of netstat -a shows
>   TCP    BRAMSCHE:4462          BRAMSCHE:0             ABHTREN
>   TCP    BRAMSCHE:4464          BRAMSCHE:4462          WARTEND
>   TCP    BRAMSCHE:4474          BRAMSCHE:0             ABHTREN

The dcopserver uses a unix domain socket path below.
$ cat ~/.DCOPserver_BRAMSCHE_BRAMSCHE-0

.local/BRAMSCHE:/tmp/.ICE-unix/2612
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2612

The respective ICE socket file shows the following

habacker@BRAMSCHE ~/src/cvs.cygwin.com/src/winsup/cygwin
$ cat /tmp/.ICE-unix/2612
.!<socket >4462 F44D504D-189AA33E-F06C24E4-2E5D38A0
           ^^^^ This is the above mentioned port in use.

Can anyone confirm this ?

Because the cygwin-daemon branch provides the long missed ipc support, the way for for speeding up unix domain
sockets with a shared memory implementation may be free. (I not be not first one, who tells about this, because I
have seen some guys before talking about this possibility)

I've played a while with the cygwin-deamon source how to implement this and have got a quick and dirty
implementation of this so think I have catched the important todos (see below), but I may be wrong in some cases.
So I'm asking for comments to this topics.

TODO:
1. create a new file fhandler_local.cc and implement the needed socket functions like
bind/listen/connect/read/write/fixup after fork and so on.
2. add the tcp/ip relates stuff from net.cc main socket functions like bind/listen/connect/read/write into
fhandler_socket.cc
3. reorganice net.cc so that the functions of fhandler_socket.cc or fhandler_local.cc depending on the socket type
are used.

1a. For each socket instance, which calls bind() and listen() there has to be created a shared memory area
identifed by the path name, which contains two regions, one for each direction and some counters and pointers for
buffer filling and empting handling.
1b. For each socket instance, which uses connect() it has to connect to the related shared memory area identified
by the path name.

One open topic for me is how to handle forking. I imagine, that because the file handles are duplicated, the shared
memory has to be duplicatd too, but because the socket file name is the same, does it use the same shared memory
area as the parent or not ???

My intention whis this thread is to make sure, that this strategy is a possible way and I'm willing to spent some t
ime to get this running, although I think I'm not be able to handle this whole task alone.

Regards

Ralf



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: unix domain socket with shared memory ?

[Corinna Vinschen]

On Wed, Feb 06, 2002 at 03:17:27PM +0100, Ralf Habacker wrote:
> Some guys may say, unix domain sockets are not implemented through tcp connection, but I'm relative sure, that this
> is true:

Huh?  Why are you "relative" sure?  Didn't you take a look into
the Cygwin sources which would be the right place to learn how
something's implemented?  net.cc is a good starting point.

I'm a bit surprised by your results, though.  Since AF_LOCAL
and AF_INET are implemented the same way, they should be
nearly equally fast^Wslow.  AF_LOCAL just has a bit of an
overhead by some additional tests but the naked read() and
write() calls should be nearly equivalent.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: unix domain socket with shared memory ?

[Ralf Habacker]

>
> On Wed, Feb 06, 2002 at 03:17:27PM +0100, Ralf Habacker wrote:
> > Some guys may say, unix domain sockets are not implemented through tcp connection, but I'm relative
> sure, that this
> > is true:
>
> Huh?  Why are you "relative" sure?  Didn't you take a look into
> the Cygwin sources which would be the right place to learn how
> something's implemented?  net.cc is a good starting point.

Of course, I have studied net.cc and fhandler_socket.cc, like but while working with cygwin I have got some
irritations, so I starting writing "relative", but now because you have confirmed my thoughts, I can write "I know"
instead of "relativ" sure :-)

> I'm a bit surprised by your results, though.  Since AF_LOCAL
> and AF_INET are implemented the same way, they should be
> nearly equally fast^Wslow.  AF_LOCAL just has a bit of an
> overhead by some additional tests but the naked read() and
> write() calls should be nearly equivalent.
>
Some difference is caused by choosing the ip adress on the tcp benchmark (localhost or a real ip adress) The tcp
benchmark uses localhost, you can see this below, but there still remains a gap between the tcp (bw_tcp) and unix
domain sockets (bw_unix) benchmarks.

$ ./bw_tcp -s
starting tcp server

$ ./bw_tcp localhost
Socket bandwidth using localhost: 41.45 MB/sec

$ ./bw_tcp localhost
Socket bandwidth using localhost: 41.07 MB/sec

$ ./bw_tcp bramsche
Socket bandwidth using bramsche: 34.60 MB/sec

$ ./bw_tcp bramsche
Socket bandwidth using bramsche: 34.65 MB/sec

$ ./bw_unix
AF_UNIX sock stream bandwidth: 17.43 MB/sec

$ ./bw_unix
AF_UNIX sock stream bandwidth: 16.72 MB/sec

One question: Does unix domain sockets uses localhost address ? net.cc:cygwin_socketpair() seems to use first an ip
adress of zero and later the loopback address. Could this have an effect ?
I have tried to replace the locations using INADDR_ANY with htonl (INADDR_LOOPBACK) but recognized no changes.

cygwin_socketpair()
<snip>
  sock_in.sin_addr.s_addr = INADDR_ANY;
  if (bind (newsock, (struct sockaddr *) &sock_in, sizeof (sock_in)) < 0)
<snip>
  /* Force IP address to loopback */
  sock_in.sin_addr.s_addr = htonl (INADDR_LOOPBACK);
  if (type == SOCK_DGRAM)
    sock_out.sin_addr.s_addr = htonl (INADDR_LOOPBACK);
  /* Do a connect */
  if (connect (outsock, (struct sockaddr *) &sock_in,
<snip>

The benchmark loops seems to be equal (except the write of the forked server process in bw_unix)

... from previous created straced straced bw_unix
  127 1979351 [main] bw_unix 1788 fhandler_base::ready_for_read: read_ready 1, avail 1
 4749 1863604 [main] bw_unix 1876 _write: 65536 = write (4, 0xA012048, 65536)
  184 1863788 [main] bw_unix 1876 _write: write (4, 0xA012048, 65536)
 1966 1981317 [main] bw_unix 1788 _read: 32708 = read (3, 0xA012048, 65536), errno 0
  317 1981634 [main] bw_unix 1788 _read: read (3, 0xA012048, 65536) blocking, sigcatchers 0
  133 1981767 [main] bw_unix 1788 peek_socket: considering handle 0x210
  124 1981891 [main] bw_unix 1788 peek_socket: adding read fd_set /dev/streamsocket, fd 3
  176 1982067 [main] bw_unix 1788 peek_socket: WINSOCK_SELECT returned 1
  142 1982209 [main] bw_unix 1788 fhandler_base::ready_for_read: read_ready 1, avail 1
 1042 1983251 [main] bw_unix 1788 _read: 32708 = read (3, 0xA012048, 65536), errno 0
  307 1983558 [main] bw_unix 1788 _read: read (3, 0xA012048, 65536) blocking, sigcatchers 0
  132 1983690 [main] bw_unix 1788 peek_socket: considering handle 0x210
  121 1983811 [main] bw_unix 1788 peek_socket: adding read fd_set /dev/streamsocket, fd 3
  171 1983982 [main] bw_unix 1788 peek_socket: WINSOCK_SELECT returned 1
  127 1984109 [main] bw_unix 1788 fhandler_base::ready_for_read: read_ready 1, avail 1

... from previous created straced bw_tcp
  117 7226940 [main] bw_tcp 1792 fhandler_base::ready_for_read: read_ready 1, avail 1
 2573 7229513 [main] bw_tcp 1792 _read: 65416 = read (3, 0xA012048, 65536), errno 0
  315 7229828 [main] bw_tcp 1792 _read: read (3, 0xA012048, 65536) blocking, sigcatchers 0
  160 7229988 [main] bw_tcp 1792 peek_socket: considering handle 0x1F8
  113 7230101 [main] bw_tcp 1792 peek_socket: adding read fd_set /dev/tcp, fd 3
  165 7230266 [main] bw_tcp 1792 peek_socket: WINSOCK_SELECT returned 1
  117 7230383 [main] bw_tcp 1792 fhandler_base::ready_for_read: read_ready 1, avail 1
 2601 7232984 [main] bw_tcp 1792 _read: 65416 = read (3, 0xA012048, 65536), errno 0
  427 7233411 [main] bw_tcp 1792 _read: read (3, 0xA012048, 65536) blocking, sigcatchers 0
  128 7233539 [main] bw_tcp 1792 peek_socket: considering handle 0x1F8
  110 7233649 [main] bw_tcp 1792 peek_socket: adding read fd_set /dev/tcp, fd 3
  164 7233813 [main] bw_tcp 1792 peek_socket: WINSOCK_SELECT returned 1
  116 7233929 [main] bw_tcp 1792 fhandler_base::ready_for_read: read_ready 1, avail 1

If you look a little deeper you can see, that the read() in unix domain socket benchmark returns only 32708 bytes

 1966 1981317 [main] bw_unix 1788 _read: 32708 = read (3, 0xA012048, 65536), errno 0

while the read() in the tcp benchmark returns 65416

 2573 7229513 [main] bw_tcp 1792 _read: 65416 = read (3, 0xA012048, 65536), errno 0

and thats may be a reason for the performance difference.

The main difference between the two benchmarks are the used device /dev/sockstream against /dev/tcp.
But don't ask me about the reason why, now I'm left

Do you have any idea ?

BTW: If you are wondering about the result of 65416 in the second line above instead of the excepted 65536. It is
returned stable after a few (about 10) returns with the full buffer size of 65536 in the main benchmark loop. Could
this be a bug in the winsock code or is it be caused by timing differences, because not all data is send early
enough ? (There are 119 bytes  missed)

BTW2:
> I'm a bit surprised by your results, though.
I'm additional surprised that the native unix domain sockets performance under cygwiwn is only 7% of the linux
performance with the same hardware, while the tcp performance seems to be acceptable (64% of the linux
performance). So my main target is to speed this up. :-)

Ralf




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: unix domain socket with shared memory ?

[Corinna Vinschen]

On Thu, Feb 07, 2002 at 11:55:31PM +0100, Ralf Habacker wrote:
> One question: Does unix domain sockets uses localhost address ? net.cc:cygwin_socketpair() seems to use first an ip
> adress of zero and later the loopback address. Could this have an effect ?

Nope.  It's probably more secure to use INADDR_LOOPBACK here but
it has nothing to do with speed.

> I have tried to replace the locations using INADDR_ANY with htonl (INADDR_LOOPBACK) but recognized no changes.

I would have lost a bet if that had changed anything.

> If you look a little deeper you can see, that the read() in unix domain socket benchmark returns only 32708 bytes
> 
>  1966 1981317 [main] bw_unix 1788 _read: 32708 = read (3, 0xA012048, 65536), errno 0
> 
> while the read() in the tcp benchmark returns 65416
> 
>  2573 7229513 [main] bw_tcp 1792 _read: 65416 = read (3, 0xA012048, 65536), errno 0
> 
> and thats may be a reason for the performance difference.

Hmm, perhaps.  I've just checked in a fix which perhaps changes
that disproportion.  Could you please check with the latest from
CVS aggain?

> The main difference between the two benchmarks are the used device /dev/sockstream against /dev/tcp.
> But don't ask me about the reason why, now I'm left

That's easily to see in the sources.  net.cc?

> returned stable after a few (about 10) returns with the full buffer size of 65536 in the main benchmark loop. Could
> this be a bug in the winsock code or is it be caused by timing differences, because not all data is send early
> enough ? (There are 119 bytes  missed)

Dunno.  Winsock overhead, perhaps.

> BTW2:
> > I'm a bit surprised by your results, though.
> I'm additional surprised that the native unix domain sockets performance under cygwiwn is only 7% of the linux
> performance with the same hardware, while the tcp performance seems to be acceptable (64% of the linux
> performance). So my main target is to speed this up. :-)

That's not a surprise.  AF_LOCAL sockets are naturally equaly slow
or slower than AF_INET sockets on Cygwin (why?  Exercise for the
reader!) while they are a completely independent implementation
on Linux or other OSes.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: unix domain socket with shared memory ?

[Ralf Habacker]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Corinna Vinschen
> Sent: Friday, February 08, 2002 12:56 PM
> To: cygwin
> Subject: Re: unix domain socket with shared memory ?
>
>
> On Thu, Feb 07, 2002 at 11:55:31PM +0100, Ralf Habacker wrote:
> > One question: Does unix domain sockets uses localhost address ? net.cc:cygwin_socketpair() seems to
> use first an ip
> > adress of zero and later the loopback address. Could this have an effect ?
>
> Nope.  It's probably more secure to use INADDR_LOOPBACK here but
> it has nothing to do with speed.
>
> > I have tried to replace the locations using INADDR_ANY with htonl (INADDR_LOOPBACK) but recognized no changes.
>
> I would have lost a bet if that had changed anything.

I should add, it does not have any changes relating to the benchmark results. :-)

> > If you look a little deeper you can see, that the read() in unix domain socket benchmark returns only
> 32708 bytes
> >
> >  1966 1981317 [main] bw_unix 1788 _read: 32708 = read (3, 0xA012048, 65536), errno 0
> >
> > while the read() in the tcp benchmark returns 65416
> >
> >  2573 7229513 [main] bw_tcp 1792 _read: 65416 = read (3, 0xA012048, 65536), errno 0
> >
> > and thats may be a reason for the performance difference.
>
> Hmm, perhaps.  I've just checked in a fix which perhaps changes
> that disproportion.  Could you please check with the latest from
> CVS aggain?
>
Yes, i will try.

> > The main difference between the two benchmarks are the used device /dev/sockstream against /dev/tcp.
> > But don't ask me about the reason why, now I'm left
>
> That's easily to see in the sources.  net.cc?
>
I have assumed, that there are perhaps some hided implementation difference, which causes this buffer size
difference. :-

> > returned stable after a few (about 10) returns with the full buffer size of 65536 in the main
> benchmark loop. Could
> > this be a bug in the winsock code or is it be caused by timing differences, because not all data is send early
> > enough ? (There are 119 bytes  missed)
>
> Dunno.  Winsock overhead, perhaps.
>
> > BTW2:
> > > I'm a bit surprised by your results, though.
> > I'm additional surprised that the native unix domain sockets performance under cygwiwn is only 7% of the linux
> > performance with the same hardware, while the tcp performance seems to be acceptable (64% of the linux
> > performance). So my main target is to speed this up. :-)
>
> That's not a surprise.  AF_LOCAL sockets are naturally equaly slow
> or slower than AF_INET sockets on Cygwin (why?  Exercise for the
> reader!) while they are a completely independent implementation
> on Linux or other OSes.
Your're right, it's not a suprise for someone who know how cygwin implements AF_LOCAL :-), but of the sight from
linux, this isn't expected


I'm porting kde, which comes from linux or other unix and the contained libs and apps expects a faster
implementation of AF_LOCAL.
And because I'm trying to speed up kde running, this optimation looks good to me. My question is now, what do you
think about this idea with a shared memory implementation of AF_LOCAL ?

Ralf



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: unix domain socket with shared memory ?

[Ralf Habacker]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Corinna Vinschen
> Sent: Friday, February 08, 2002 12:56 PM
> To: cygwin
> Subject: Re: unix domain socket with shared memory ?
>
>
> On Thu, Feb 07, 2002 at 11:55:31PM +0100, Ralf Habacker wrote:
> > One question: Does unix domain sockets uses localhost address ? net.cc:cygwin_socketpair() seems to
> use first an ip
> > adress of zero and later the loopback address. Could this have an effect ?
>
> Nope.  It's probably more secure to use INADDR_LOOPBACK here but
> it has nothing to do with speed.
>
> > I have tried to replace the locations using INADDR_ANY with htonl (INADDR_LOOPBACK) but recognized no changes.
>
> I would have lost a bet if that had changed anything.

I should add, it does not have any changes relating to the benchmark results. :-)

> > If you look a little deeper you can see, that the read() in unix domain socket benchmark returns only
> 32708 bytes
> >
> >  1966 1981317 [main] bw_unix 1788 _read: 32708 = read (3, 0xA012048, 65536), errno 0
> >
> > while the read() in the tcp benchmark returns 65416
> >
> >  2573 7229513 [main] bw_tcp 1792 _read: 65416 = read (3, 0xA012048, 65536), errno 0
> >
> > and thats may be a reason for the performance difference.
>
> Hmm, perhaps.  I've just checked in a fix which perhaps changes
> that disproportion.  Could you please check with the latest from
> CVS aggain?
>
Yes, i will try.

> > The main difference between the two benchmarks are the used device /dev/sockstream against /dev/tcp.
> > But don't ask me about the reason why, now I'm left
>
> That's easily to see in the sources.  net.cc?
>
I have assumed, that there are perhaps some hided implementation difference, which causes this buffer size
difference. :-

> > returned stable after a few (about 10) returns with the full buffer size of 65536 in the main
> benchmark loop. Could
> > this be a bug in the winsock code or is it be caused by timing differences, because not all data is send early
> > enough ? (There are 119 bytes  missed)
>
> Dunno.  Winsock overhead, perhaps.
>
> > BTW2:
> > > I'm a bit surprised by your results, though.
> > I'm additional surprised that the native unix domain sockets performance under cygwiwn is only 7% of the linux
> > performance with the same hardware, while the tcp performance seems to be acceptable (64% of the linux
> > performance). So my main target is to speed this up. :-)
>
> That's not a surprise.  AF_LOCAL sockets are naturally equaly slow
> or slower than AF_INET sockets on Cygwin (why?  Exercise for the
> reader!) while they are a completely independent implementation
> on Linux or other OSes.
Your're right, it's not a suprise for someone who know how cygwin implements AF_LOCAL :-), but of the sight from
linux, this isn't expected


I'm porting kde, which comes from linux or other unix and the contained libs and apps expects a faster
implementation of AF_LOCAL.
And because I'm trying to speed up kde running, this optimation looks good to me. My question is now, what do you
think about this idea with a shared memory implementation of AF_LOCAL ?

Ralf



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: unix domain socket with shared memory ?

[Robert Collins]

===
----- Original Message -----
From: "Ralf Habacker" <Ralf.Habacker@sag-el.com>
To: "cygwin" <cygwin@cygwin.com>
Sent: Thursday, February 07, 2002 1:17 AM
Subject: unix domain socket with shared memory ?


> Hi all,
>
> cfg has told me about the current process of cygwin daemon
implementation with ipc support.
>
> I initial have heard last year, that this work would be started, but
because of so much other work I have lost the
> contact to the ongoing process.

It's currently paused, waiting for the development team to persuade
Chris that the _core_ (not the IPC part) is ready for (finaly filenaming
and then) inclusion.

> Now I was looking into the ongoing work and it seems to me in a mostly
read state, isn't it. I like to say: Great
> work to all who have worked on it. :-)

Thank you. The main folk are Egor Duda who created an inital
proof-of-concept for solving a security issue, most of the developers
list bouncing round ideas, and then I (*bow*) took Egors proof of
concept and created the generic daemon, and the win9x support that it
now has. Gary R. Van Sickle has also spent some time recently being a
guinea pig, which I appreciate :].

> The reason why I'm writing this is that I have recognized some
performance issues with unix domain sockets, which
...

> Because the cygwin-daemon branch provides the long missed ipc support,
the way for for speeding up unix domain
> sockets with a shared memory implementation may be free. (I not be not
first one, who tells about this, because I
> have seen some guys before talking about this possibility)

Hmm, the cygwin-daemon IPC implementation may allow this, but so does
the existing mmap implementation. So I think a better approach may be
via mmap (more mature code) with the daemon providing
cross-process-persistence (if needed).

> One open topic for me is how to handle forking. I imagine, that
because the file handles are duplicated, the shared
> memory has to be duplicatd too, but because the socket file name is
the same, does it use the same shared memory
> area as the parent or not ???

Forking is easy to implement (see the fixup_after_fork functions) but
shouldn't be needed if implemented on top of mmap or IPC memory regions.
What maybe an issue is the logic for how it should behave.

If you write, who reads? The parent or the child? The first reader? Once
this question is answered, you will find making fork() work straight
forward. Advice can be offered at that point if needed.

> My intention whis this thread is to make sure, that this strategy is a
possible way and I'm willing to spent some t
> ime to get this running, although I think I'm not be able to handle
this whole task alone.

Yes, it's possible. Is the daemon needed? Maybe not, maybe. You will get
assistance in doing this.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: unix domain socket with shared memory ?

[Ralf Habacker]

> > > If you look a little deeper you can see, that the read() in unix domain socket benchmark returns only
> > 32708 bytes
> > >
> > >  1966 1981317 [main] bw_unix 1788 _read: 32708 = read (3, 0xA012048, 65536), errno 0
> > >
> > > while the read() in the tcp benchmark returns 65416
> > >
> > >  2573 7229513 [main] bw_tcp 1792 _read: 65416 = read (3, 0xA012048, 65536), errno 0
> > >
> > > and thats may be a reason for the performance difference.
> >
> > Hmm, perhaps.  I've just checked in a fix which perhaps changes
> > that disproportion.  Could you please check with the latest from
> > CVS aggain?
> >
> Yes, i will try.

The result is the same as before. bw_unix reports 32708 returned bytes also. After thinking a while about this, I
recognized that one major difference between tcp and unix domain benchmark is that the unix socket benchmark uses
fork to create the server process and afterthat enter the reading loop (one ./bw_unix), while on tcp a seperate
process has be started on the command line ./bw_tcp -s and than the client ./bw_tcp localhost.

I have looked on the strace outputs to find some significat difference for this topic, but found nothing.
I have reduced the predefined transfer size to 65500 and 34000 so see if there are some limits in the maximum
buffer size, which would be wrapped, but the same result also. :-(

Ralf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: unix domain socket with shared memory ?

[Ralf Habacker]

[-- Attachment #1: Type: text/plain, Size: 8925 bytes --]

http://i30www.ira.uka.de/courses/winter00-01/Prosem_LinuxInternals/4.4ipc.ppt

> > Hi all,
> >
> > cfg has told me about the current process of cygwin daemon
> implementation with ipc support.
> >
> > I initial have heard last year, that this work would be started, but
> because of so much other work I have lost the
> > contact to the ongoing process.
>
> It's currently paused, waiting for the development team to persuade
> Chris that the _core_ (not the IPC part) is ready for (finaly filenaming
> and then) inclusion.
>
> > Now I was looking into the ongoing work and it seems to me in a mostly
> read state, isn't it. I like to say: Great
> > work to all who have worked on it. :-)
>
> Thank you. The main folk are Egor Duda who created an inital
> proof-of-concept for solving a security issue, most of the developers
> list bouncing round ideas, and then I (*bow*) took Egors proof of
> concept and created the generic daemon, and the win9x support that it
> now has. Gary R. Van Sickle has also spent some time recently being a
> guinea pig, which I appreciate :].
>
> > The reason why I'm writing this is that I have recognized some
> performance issues with unix domain sockets, which
> ...
>
> > Because the cygwin-daemon branch provides the long missed ipc support,
> the way for for speeding up unix domain
> > sockets with a shared memory implementation may be free. (I not be not
> first one, who tells about this, because I
> > have seen some guys before talking about this possibility)
>
> Hmm, the cygwin-daemon IPC implementation may allow this, but so does
> the existing mmap implementation. So I think a better approach may be
> via mmap (more mature code) with the daemon providing
> cross-process-persistence (if needed).
>
> > One open topic for me is how to handle forking. I imagine, that
> because the file handles are duplicated, the shared
> > memory has to be duplicatd too, but because the socket file name is
> the same, does it use the same shared memory
> > area as the parent or not ???
>
> Forking is easy to implement (see the fixup_after_fork functions) but
> shouldn't be needed if implemented on top of mmap or IPC memory regions.
> What maybe an issue is the logic for how it should behave.
>
> If you write, who reads? The parent or the child? The first reader? Once
> this question is answered, you will find making fork() work straight
> forward. Advice can be offered at that point if needed.
>

How is it implemented in the current implementation ?

> > My intention whis this thread is to make sure, that this strategy is a
> possible way and I'm willing to spent some t
> > ime to get this running, although I think I'm not be able to handle
> this whole task alone.
>
> Yes, it's possible. Is the daemon needed? Maybe not, maybe. You will get
> assistance in doing this.
>
So this is my current strategy for the beginning.

The first task seems to me to reorganice net.cc, so that all AF_INET/AF_LOCAL specific functions are located into
methods of fhandler_socket. After doing this net.cc contains only wrappers for the above mentioned functions.

See a snippet of my current fhandler.h

class fhandler_socket
....
#ifdef NEW_NET
  // a FIXME means, this functions isn't moved into class fhandler_socket yet
  // a CHECK means, this functions is implemented and has to be check for valid functionality

  // FIXME: move from net.cc to fhandler_socker.cc
  int socketpair (int family, int type, int protocol, int *sb);
  // FIXME: move from net.cc to fhandler_socker.cc
  int socket (int af, int type, int protocol);
  // CHECK:
  int bind (const struct sockaddr *my_addr, int addrlen);
  // CHECK:
  int listen (int backlog);
  // CHECK:
  int accept (struct sockaddr *peer, int *len);
  // CHECK:
  int recv (const void *buf, int len, unsigned int flags);
  // CHECK:
  int send (const void *buf, int len, unsigned int flags);
  // CHECK:
  int connect (const struct sockaddr *name, int namelen);
  // CHECK:
  int shutdown (int how);
  // CHECK:
  int getsockname (struct sockaddr *addr, int *namelen);
  // CHECK:
  int getpeername (struct sockaddr *name, int *len);
#endif

This seems to me as a general optimation, which should be incorporated also in the main cygwin branch, because it
would simplifies the process of integrating other socket implementations. Any comments to this ?

The second task is to fork a new fhandler_local class from fhandler_socket, change the above mentioned methods into
virtual methods, which contains all AF_LOCAL specific stuff.

Perhaps is is better to create a base fhandler_socket class with virtual functions and than derivate
fhandler_socket_tcp (which is currently named fhandler_socket) and fhandler_socket_local from this.

net.cc and other files should only use the basic socket class "fhandler_socket", so that the right virtual
functions are used.

This class has be added to the fhandler instance creation dispatcher in path.cc.
I have also seen some FH_SOCKET related stuff in dtable.cc:dtable::release() and net.cc:fdsock(). In fdsock, the
depending on the protocol familiy, the propper objects should be created from fhandler_socket_tcp for tcp sockets
and fhandler_socket_local for unix domain sockets.

If the current fhandler_socket.cc is copied into fhandler_socket_tcp.cc and fhandler_socket_local.cc in this step,
the cygwin1.dll should work as before, because the changes has no functionality changed only source layout.

This step could be also done in the main cygwin tree.

The third step seems to me to implement the new af_local stuff in fhandler_socket_local.cc, which should be
discussed. A sample implementation could be found unter
http://i30www.ira.uka.de/courses/winter00-01/Prosem_LinuxInternals/4.4ipc.ppt, but currently I don't know if there
are some copyrights on this.

For step one a patch is appended (about 95% complete, socket and socketpair are missing, because they don't use an
existing fhandler_socket, instead they create such, so integrating it into fhandler_socket seems not right for me).
The patch was created from the winsup dir assuming that the cygwin-daemon source is located into cygwin-daemon.
Additional it uses a MACRO named NEW_NET, which enables the moved code. If this macro is unset the present
implementation is used. (see Makefile.in)
Because I have checked out the winsup/cygwin tree and the winsup/cygwin-daemon tree in one directory, a patched
winsup/Makefile.common-daemon is needed.
This isn't a ready-for-check-in-patch, so I don't have added a ChangeLog. Also there are no functionality changes,
so I think no copyright assignment is nessessary.
I see this patch as as discussion base. Any comments ?
I have verified propper operation with a sample unix socket client/server from
http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html. I know, that this does not check all patched methods, so
it would be nice if somebody else could add some tests.

Note: There may be some need to add some sigframe lines, but I'm not sure, where this should be placed.

Another topic which would be nesessary to observe seems to me be the comunication latencies, which the benchmark
shows.
Currently I don't know how much the influence on unix domain socket performance is, but what I see is that for pies
and AF_UNIX the latency are about 700 times respective 370 times more thant for linux with the same hardware.
Tcp shows similar results. UDP has a latency of more than 100 and tcp about 2570 times.

*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
BRAMSCHE  CYGWIN_NT-5.0 4970. 14.7K 14.K 107.1       13.5K       550K
BRAMSCHE   Linux 2.2.18 3.290  19.2 39.6  76.8  85.3 128.0 238.0 214.
                               ^^^^ ^^^^             ^^^^        ^^^^
Currently it seems to me, that this latencies are caused by the windows and/or cygwin context/task switching
implementation.

The reason why I suggess this are

1. context switching seems to be a general optimization topic if you see in the results shown below.

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host                 OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                        ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
BRAMSCHE  CYGWIN_NT-5.0 4970. 5959.5 5933.2 3177.0 8706.5  4218.8  6200.8
BRAMSCHE   Linux 2.2.18 3.530   12.6   25.1   19.8  161.3    31.4   162.6

2. UDP transfer has much less latencies, so this says it is possible to avoid latencies, but I haven't found the
difference yet.

Any comments ?

Ralf









[-- Attachment #2: cygwin-daemon_NEW_NET_01.patch --]
[-- Type: application/octet-stream, Size: 18688 bytes --]

? cygwin-daemon/.new.ROADMAP
? cygwin-daemon/fhandler.h_new_af_local
? cygwin-daemon/fhandler_local.cc
? cygwin-daemon/fhandler_socket.cc_new_af_local
? cygwin-daemon/net.cc_new_af_local
? cygwin-daemon/SharedMem.cc
? cygwin-daemon/SharedMem.h
Index: cygwin-daemon//Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/Makefile.in,v
retrieving revision 1.63.2.11
diff -u -b -B -r1.63.2.11 Makefile.in
--- Makefile.in	2002/01/29 09:48:25	1.63.2.11
+++ Makefile.in	2002/02/10 20:28:49
@@ -51,7 +51,7 @@
 # FIXME: Which is it, CC or CC_FOR_TARGET?
 CC_FOR_TARGET:=$(CC)
 CFLAGS:=@CFLAGS@
-CFLAGS+=-MMD -fbuiltin
+CFLAGS+=-MMD -fbuiltin -DNEW_NET 
 CXX:=@CXX@
 CXXFLAGS:=@CXXFLAGS@
 
@@ -71,7 +71,7 @@
 #
 # Include common definitions for winsup directory
 #
-include $(srcdir)/../Makefile.common
+include $(srcdir)/../Makefile.common-daemon
 
 INSTALL_DATA:=$(SHELL) $(updir1)/install-sh -c
 
@@ -202,8 +202,8 @@
 	    $(INSTALL_DATA) $$i $(tooldir)/man/man7/`basename $$i` ; \
 	done
 
-install_target: cygserver.exe
-	$(INSTALL_PROGRAM) cygserver.exe $(bindir)/cygserver.exe
+install-bin: cygserver.exe
+	$(INSTALL_DATA) cygserver.exe $(bindir)/cygserver.exe
 	
 install_host:
 
Index: cygwin-daemon//fhandler.h
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler.h,v
retrieving revision 1.83.2.4
diff -u -b -B -r1.83.2.4 fhandler.h
--- fhandler.h	2002/01/04 03:56:07	1.83.2.4
+++ fhandler.h	2002/02/10 20:28:53
@@ -402,7 +402,41 @@
   void signal_secret_event ();
   void close_secret_event ();
   int __stdcall fstat (struct stat *buf, path_conv *) __attribute__ ((regparm (3)));
+#if NEW_NET
+	// a FIXME means, this functions isn't moved into class fhandler_socket
+	// a CHECK means, check this function of valid functionality 
+
+  // FIXME: move from net.cc to fhandler_socker.cc
+	int socketpair (int family, int type, int protocol, int *sb); 
+  // FIXME: move from net.cc to fhandler_socker.cc
+  int socket (int af, int type, int protocol);
+  // CHECK: 
+  int bind (const struct sockaddr *my_addr, int addrlen); 
+  // CHECK: 
+	int listen (int backlog);
+  // CHECK: 
+	int accept (struct sockaddr *peer, int *len);
+  // CHECK: 
+	int recv (const void *buf, int len, unsigned int flags);
+  // CHECK: 
+	int send (const void *buf, int len, unsigned int flags);
+  // CHECK: 
+	int connect (const struct sockaddr *name, int namelen);
+  // CHECK: 
+	int shutdown (int how);
+  // CHECK: 
+	int getsockname (struct sockaddr *addr, int *namelen); 
+  // CHECK: 
+	int getpeername (struct sockaddr *name, int *len);
+#endif 
 };
+
+class fhandler_local: public fhandler_socket
+{ 
+  private:
+
+ public: 	
+}; 
 
 class fhandler_pipe: public fhandler_base
 {
Index: cygwin-daemon//fhandler_socket.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler_socket.cc,v
retrieving revision 1.24.2.2
diff -u -b -B -r1.24.2.2 fhandler_socket.cc
--- fhandler_socket.cc	2002/01/04 03:56:08	1.24.2.2
+++ fhandler_socket.cc	2002/02/10 20:28:55
@@ -10,11 +10,14 @@
 
 /* #define DEBUG_NEST_ON 1 */
 
+#define DEBUG 1
+
 #define  __INSIDE_CYGWIN_NET__
 
 #include "winsup.h"
 #include <errno.h>
 #include <sys/socket.h>
+#include <sys/un.h>
 #include <asm/byteorder.h>
 
 #include <stdlib.h>
@@ -93,7 +96,7 @@
   struct sockaddr_in sin;
   int sin_len = sizeof (sin);
 
-  if (getsockname (get_socket (), (struct sockaddr*) &sin, &sin_len))
+  if (::getsockname (get_socket (), (struct sockaddr*) &sin, &sin_len))
     {
       debug_printf ("error getting local socket name (%d)", WSAGetLastError ());
       return NULL;
@@ -255,7 +258,7 @@
 fhandler_socket::read (void *ptr, size_t len)
 {
   sigframe thisframe (mainthread);
-  int res = recv (get_socket (), (char *) ptr, len, 0);
+  int res = ::recv (get_socket (), (char *) ptr, len, 0);
   if (res == SOCKET_ERROR)
     set_winsock_errno ();
   return res;
@@ -265,7 +268,7 @@
 fhandler_socket::write (const void *ptr, size_t len)
 {
   sigframe thisframe (mainthread);
-  int res = send (get_socket (), (const char *) ptr, len, 0);
+  int res = ::send (get_socket (), (const char *) ptr, len, 0);
   if (res == SOCKET_ERROR)
     {
       set_winsock_errno ();
@@ -488,3 +491,394 @@
     cfree (sun_path);
   sun_path = cstrdup (path);
 }
+
+#if NEW_NET
+fhandler_socket *
+fdsock (int& fd, const char *name, SOCKET soc);
+
+// FIXME: this class definition is a copy from net.cc and has to updated 
+// there in case of making any changes here. 
+// The hack is done, because putting this class from net.cc into fhandler.h 
+// needs some more work, which I cannot oversee yet. 
+class wsock_event
+{
+  WSAEVENT		event;
+  WSAOVERLAPPED		ovr;
+public:
+  wsock_event () : event (NULL) {};
+  ~wsock_event ()
+    {
+      if (event)
+	WSACloseEvent (event);
+      event = NULL;
+    };
+
+  LPWSAOVERLAPPED prepare ();
+  int wait (int socket, LPDWORD flags);
+};
+
+
+int fhandler_socket::socket (int af, int type, int protocol)
+{
+	return -1; 
+}
+
+int fhandler_socket::bind (const struct sockaddr *my_addr, int addrlen)
+{
+	int res = -1;
+	
+	if (my_addr->sa_family == AF_LOCAL)
+	{
+#define un_addr ((struct sockaddr_un *) my_addr)
+	  struct sockaddr_in sin;
+	  int len = sizeof sin;
+
+	  if (strlen (un_addr->sun_path) >= UNIX_PATH_LEN)
+	    {
+	      set_errno (ENAMETOOLONG);
+	      goto out;
+	    }
+
+	  sin.sin_family = AF_INET;
+	  sin.sin_port = 0;
+	  sin.sin_addr.s_addr = htonl (INADDR_LOOPBACK);
+	  if (::bind (get_socket (), (sockaddr *) &sin, len))
+	    {
+	      syscall_printf ("AF_LOCAL: bind failed %d", get_errno ());
+	      set_winsock_errno ();
+	      goto out;
+	    }
+	  if (::getsockname (get_socket (), (sockaddr *) &sin, &len))
+	    {
+	      syscall_printf ("AF_LOCAL: getsockname failed %d", get_errno ());
+	      set_winsock_errno ();
+	      goto out;
+	    }
+
+	  sin.sin_port = ntohs (sin.sin_port);
+	  debug_printf ("AF_LOCAL: socket bound to port %u", sin.sin_port);
+
+	  /* bind must fail if file system socket object already exists
+	     so _open () is called with O_EXCL flag. */
+	  int _fd = _open (un_addr->sun_path,
+		      O_WRONLY | O_CREAT | O_EXCL | O_BINARY,
+		      0);
+	  if (_fd < 0)
+	    {
+	      if (get_errno () == EEXIST)
+		set_errno (EADDRINUSE);
+	      goto out;
+	    }
+
+	  set_connect_secret ();
+
+	  char buf[sizeof (SOCKET_COOKIE) + 80];
+	  __small_sprintf (buf, "%s%u ", SOCKET_COOKIE, sin.sin_port);
+	  get_connect_secret (strchr (buf, '\0'));
+	  len = strlen (buf) + 1;
+
+	  /* Note that the terminating nul is written.  */
+	  if (_write (_fd, buf, len) != len)
+	    {
+	      save_errno here;
+	      _close (_fd);
+	      _unlink (un_addr->sun_path);
+	    }
+	  else
+	    {
+	      _close (_fd);
+	      chmod (un_addr->sun_path,
+		(S_IFSOCK | S_IRWXU | S_IRWXG | S_IRWXO) & ~cygheap->umask);
+	      set_sun_path (un_addr->sun_path);
+	      res = 0;
+	    }
+#undef un_addr
+	}
+      else if (::bind (get_socket (), my_addr, addrlen))
+	set_winsock_errno ();
+      else
+	res = 0;
+
+out:
+  return res;
+}
+
+int fhandler_socket::listen (int backlog)
+{    
+	int res = ::listen (get_socket (), backlog);
+  	if (res)
+	set_winsock_errno ();
+	return res;
+}
+
+int fhandler_socket::accept (struct sockaddr *peer, int *len)
+{
+  BOOL secret_check_failed = FALSE;
+  BOOL in_progress = FALSE;
+  sigframe thisframe (mainthread);
+	int res = -1;
+	{
+  /* Allows NULL peer and len parameters. */
+  struct sockaddr_in peer_dummy;
+  int len_dummy;
+
+	  if (!peer)
+	peer = (struct sockaddr *) &peer_dummy;
+      if (!len)
+	{
+	  len_dummy = sizeof (struct sockaddr_in);
+	  len = &len_dummy;
+	}
+
+      /* accept on NT fails if len < sizeof (sockaddr_in)
+       * some programs set len to
+       * sizeof (name.sun_family) + strlen (name.sun_path) for UNIX domain
+       */
+      if (len && ((unsigned) *len < sizeof (struct sockaddr_in)))
+	*len = sizeof (struct sockaddr_in);
+
+      res = ::accept (get_socket (), peer, len);  // can't use a blocking call inside a lock
+
+      if ((SOCKET) res == (SOCKET) INVALID_SOCKET &&
+	  WSAGetLastError () == WSAEWOULDBLOCK)
+	in_progress = TRUE;
+
+      if (get_addr_family () == AF_LOCAL)
+	{
+	  if ((SOCKET) res != (SOCKET) INVALID_SOCKET || in_progress)
+	    {
+	      if (!create_secret_event ())
+		secret_check_failed = TRUE;
+	      else if (in_progress)
+		signal_secret_event ();
+	    }
+
+	  if (!secret_check_failed &&
+	      (SOCKET) res != (SOCKET) INVALID_SOCKET)
+	    {
+	      if (!check_peer_secret_event ((struct sockaddr_in*) peer))
+		{
+		  debug_printf ("connect from unauthorized client");
+		  secret_check_failed = TRUE;
+		}
+	    }
+
+	  if (secret_check_failed)
+	    {
+	      close_secret_event ();
+	      if ((SOCKET) res != (SOCKET) INVALID_SOCKET)
+		closesocket (res);
+	      set_errno (ECONNABORTED);
+	      res = -1;
+	      goto done;
+	    }
+	}
+
+
+      cygheap_fdnew res_fd;
+      if (res_fd < 0)
+	/* FIXME: what is correct errno? */;
+      else if ((SOCKET) res == (SOCKET) INVALID_SOCKET)
+	set_winsock_errno ();
+      else
+	{
+	  fhandler_socket* res_fh = fdsock (res_fd, get_name (), res);
+	  if (get_addr_family () == AF_LOCAL)
+	    res_fh->set_sun_path (get_sun_path ());
+	  res_fh->set_addr_family (get_addr_family ());
+	  res = res_fd;
+	}
+ }
+ done:
+ 	return res; 
+ }
+
+int fhandler_socket::recv (const void *buf, int len, unsigned int flags)
+{
+	int res = -1;
+  wsock_event wsock_evt;
+  LPWSAOVERLAPPED ovr;
+  sigframe thisframe (mainthread);
+
+    if (is_nonblocking () || !(ovr = wsock_evt.prepare ()))
+	{
+	  debug_printf ("Fallback to winsock 1 recv call");
+	  if ((res = ::recv (get_socket (), (char *) buf, len, flags))
+	      == SOCKET_ERROR)
+	    {
+	      set_winsock_errno ();
+	      res = -1;
+	    }
+	}
+	    else
+	{
+	  WSABUF wsabuf = { len, (char *) buf };
+	  DWORD ret = 0;
+	  if (::WSARecv (get_socket (), &wsabuf, 1, &ret, (DWORD *)&flags,
+		       ovr, NULL) != SOCKET_ERROR)
+	    res = ret;
+	  else if ((res = WSAGetLastError ()) != WSA_IO_PENDING)
+	    {
+	      set_winsock_errno ();
+	      res = -1;
+	    }
+	  else if ((res = wsock_evt.wait (get_socket (), (DWORD *)&flags)) == -1)
+	    set_winsock_errno ();
+	}
+	return res; 
+}
+
+int fhandler_socket::send (const void *buf, int len, unsigned int flags)
+{
+  wsock_event wsock_evt;
+  LPWSAOVERLAPPED ovr;
+	int res = -1;
+  sigframe thisframe (mainthread);
+
+      if (is_nonblocking () || !(ovr = wsock_evt.prepare ()))
+	{
+	  debug_printf ("Fallback to winsock 1 send call");
+	  if ((res = ::send (get_socket (), (const char *) buf, len, flags))
+	      == SOCKET_ERROR)
+	    {
+	      set_winsock_errno ();
+	      res = -1;
+	    }
+	}
+      else
+	{
+	  WSABUF wsabuf = { len, (char *) buf };
+	  DWORD ret = 0;
+	  if (::WSASend (get_socket (), &wsabuf, 1, &ret, (DWORD)flags,
+		       ovr, NULL) != SOCKET_ERROR)
+	    res = ret;
+	  else if ((res = WSAGetLastError ()) != WSA_IO_PENDING)
+	    {
+	      set_winsock_errno ();
+	      res = -1;
+	    }
+	  else if ((res = wsock_evt.wait (get_socket (), (DWORD *)&flags)) == -1)
+	    set_winsock_errno ();
+	}
+	return res; 
+}
+
+int fhandler_socket::connect (const struct sockaddr *name, int namelen) 
+{
+  BOOL secret_check_failed = FALSE;
+  BOOL in_progress = FALSE;
+  sockaddr_in sin;
+  int secret [4];
+  sigframe thisframe (mainthread);
+
+	int res = ::connect (get_socket (), (sockaddr *) &sin, namelen);
+  if (res)
+	{
+	  /* Special handling for connect to return the correct error code
+	     when called on a non-blocking socket. */
+	  if (is_nonblocking ())
+	    {
+	      DWORD err = WSAGetLastError ();
+	      if (err == WSAEWOULDBLOCK || err == WSAEALREADY)
+		{
+		  WSASetLastError (WSAEINPROGRESS);
+		  in_progress = TRUE;
+		}
+	      else if (err == WSAEINVAL)
+		WSASetLastError (WSAEISCONN);
+	    }
+	  set_winsock_errno ();
+	}
+      if (get_addr_family () == AF_LOCAL)
+	{
+	  if (!res || in_progress)
+	    {
+	      if (!create_secret_event (secret))
+		{
+		  secret_check_failed = TRUE;
+		}
+	      else if (in_progress)
+		signal_secret_event ();
+	    }
+
+	  if (!secret_check_failed && !res)
+	    {
+	      if (!check_peer_secret_event (&sin, secret))
+		{
+		  debug_printf ( "accept from unauthorized server" );
+		  secret_check_failed = TRUE;
+		}
+	   }
+
+	  if (secret_check_failed)
+	    {
+	      close_secret_event ();
+	      if (res)
+		closesocket (res);
+	      set_errno (ECONNREFUSED);
+	      res = -1;
+	    }
+	}
+	return res; 
+}
+
+int fhandler_socket::shutdown (int how)
+{
+	int res = ::shutdown (get_socket (), how);
+      if (res)
+	set_winsock_errno ();
+      else
+	switch (how)
+	  {
+	  case SHUT_RD:
+	    set_shutdown_read ();
+	    break;
+	  case SHUT_WR:
+	    set_shutdown_write ();
+	    break;
+	  case SHUT_RDWR:
+	    set_shutdown_read ();
+	    set_shutdown_write ();
+	    break;
+	  }
+	return res;
+}
+
+int fhandler_socket::getsockname (struct sockaddr *addr, int *namelen)
+{
+	int res = -1; 
+
+	if (get_addr_family () == AF_LOCAL)
+	{
+	  struct sockaddr_un *sun = (struct sockaddr_un *) addr;
+	  memset (sun, 0, *namelen);
+	  sun->sun_family = AF_LOCAL;
+	  /* According to SUSv2 "If the actual length of the address is greater
+	     than the length of the supplied sockaddr structure, the stored
+	     address will be truncated."  We play it save here so that the
+	     path always has a trailing 0 even if it's truncated. */
+	  strncpy (sun->sun_path, get_sun_path (),
+		   *namelen - sizeof *sun + sizeof sun->sun_path - 1);
+	  *namelen = sizeof *sun - sizeof sun->sun_path
+		     + strlen (sun->sun_path) + 1;
+	  res = 0;
+	}
+      else
+	{
+	  res = ::getsockname (get_socket (), addr, namelen);
+	  if (res)
+	    set_winsock_errno ();
+	}
+	return res; 
+}
+
+int fhandler_socket::getpeername (struct sockaddr *name, int *len)
+{
+	int res = ::getpeername (get_socket (), name, len);
+      if (res)
+	set_winsock_errno ();    
+  return res; 
+}
+
+#endif 
+
Index: cygwin-daemon//ipc.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/Attic/ipc.cc,v
retrieving revision 1.1.2.1
diff -u -b -B -r1.1.2.1 ipc.cc
--- ipc.cc	2001/09/25 06:31:04	1.1.2.1
+++ ipc.cc	2002/02/10 20:28:55
@@ -22,7 +22,7 @@
 ftok(const char *path, int id)
 {
   struct stat statbuf;
-  if (stat(path, &statbuf))
+  if (stat(path, &statbuf) < 0)
     {
       /* stat set the appropriate errno for us */
       return (key_t) -1;
Index: cygwin-daemon//net.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/net.cc,v
retrieving revision 1.77.2.3
diff -u -b -B -r1.77.2.3 net.cc
--- net.cc	2002/01/22 04:52:40	1.77.2.3
+++ net.cc	2002/02/10 20:29:01
@@ -879,6 +878,9 @@
   if (!sock)
     res = -1;
   else
+#ifdef NEW_NET 
+		res = sock->connect(name,namelen);
+#else 
     {
       res = connect (sock->get_socket (), (sockaddr *) &sin, namelen);
       if (res)
@@ -929,6 +931,7 @@
 	    }
 	}
     }
+#endif 
   return res;
 }
 
@@ -1191,6 +1194,9 @@
 
   fhandler_socket *sock = get (fd);
   if (sock)
+#ifdef NEW_NET
+  	res = sock->accept(peer,len);
+#else 
     {
       /* Allows NULL peer and len parameters. */
       struct sockaddr_in peer_dummy;
@@ -1263,6 +1269,7 @@
 	}
     }
  done:
+#endif 
   syscall_printf ("%d = accept (%d, %x, %x)", res, fd, peer, len);
   return res;
 }
@@ -1278,6 +1285,9 @@
 
   fhandler_socket *sock = get (fd);
   if (sock)
+#ifdef NEW_NET
+  	res = sock->bind(my_addr,addrlen);
+#else 
     {
       if (my_addr->sa_family == AF_LOCAL)
 	{
@@ -1352,6 +1362,8 @@
 	res = 0;
     }
 
+#endif 
+
 out:
   syscall_printf ("%d = bind (%d, %x, %d)", res, fd, my_addr, addrlen);
   return res;
@@ -1369,6 +1381,9 @@
 
   fhandler_socket *sock = get (fd);
   if (sock)
+#ifdef NEW_NET
+  	res = sock->getsockname(addr,namelen);
+#else 
     {
       if (sock->get_addr_family () == AF_LOCAL)
 	{
@@ -1392,6 +1407,7 @@
 	    set_winsock_errno ();
 	}
     }
+#endif 
   syscall_printf ("%d = getsockname (%d, %x, %d)", res, fd, addr, namelen);
   return res;
 }
@@ -1405,11 +1421,15 @@
 
   fhandler_socket *sock = get (fd);
   if (sock)
+#ifdef NEW_NET
+  	res = sock->listen(backlog);
+#else 
     {
       res = listen (sock->get_socket (), backlog);
       if (res)
 	set_winsock_errno ();
     }
+#endif 
   syscall_printf ("%d = listen (%d, %d)", res, fd, backlog);
   return res;
 }
@@ -1423,6 +1443,9 @@
 
   fhandler_socket *sock = get (fd);
   if (sock)
+#ifdef NEW_NET
+  	res = sock->shutdown(how);
+#else 
     {
       res = shutdown (sock->get_socket (), how);
       if (res)
@@ -1442,6 +1465,7 @@
 	    break;
 	  }
     }
+#endif 
   syscall_printf ("%d = shutdown (%d, %d)", res, fd, how);
   return res;
 }
@@ -1507,12 +1530,15 @@
   if (!h)
     res = -1;
   else
+#ifdef NEW_NET
+  	res = h->getpeername(name,len);
+#else 
     {
       res = getpeername (h->get_socket (), name, len);
       if (res)
 	set_winsock_errno ();
     }
-
+#endif 
   debug_printf ("%d = getpeername %d", res, h->get_socket ());
   return res;
 }
@@ -1529,6 +1555,9 @@
   if (__check_null_invalid_struct_errno (buf, len) || !h)
     res = -1;
   else
+#ifdef NEW_NET
+  	res = h->recv(buf,len,flags);
+#else 
     {
       sigframe thisframe (mainthread);
 
@@ -1558,7 +1587,7 @@
 	    set_winsock_errno ();
 	}
     }
-
+#endif 					    
   syscall_printf ("%d = recv (%d, %x, %x, %x)", res, fd, buf, len, flags);
 
   return res;
@@ -1576,6 +1605,9 @@
   if (__check_invalid_read_ptr_errno (buf, len) || !h)
     res = -1;
   else
+#ifdef NEW_NET
+  	res = h->send(buf,len,flags);
+#else 
     {
       sigframe thisframe (mainthread);
 
@@ -1606,6 +1638,7 @@
 	}
     }
 
+#endif 
   syscall_printf ("%d = send (%d, %x, %d, %x)", res, fd, buf, len, flags);
 
   return res;

[-- Attachment #3: Makefile.common-daemon --]
[-- Type: application/octet-stream, Size: 5186 bytes --]

# Makefile.common - common definitions for the winsup directory
#
# Copyright 2000, 2001 Red Hat, Inc.
#
# This file is part of Cygwin.
#
# This software is a copyrighted work licensed under the terms of the
# Cygwin license.  Please consult the file "CYGWIN_LICENSE" for
# details.

# This makefile requires GNU make.

CFLAGS_COMMON:=-Wall -Wwrite-strings -fno-common -pipe -Winline -fbuiltin# -finline-functions
MALLOC_DEBUG:=#-DMALLOC_DEBUG -I/cygnus/src/uberbaum/winsup/cygwin-daemon/dlmalloc
MALLOC_OBJ:=#/cygnus/src/uberbaum/winsup/cygwin-daemon/dlmalloc/malloc.o

override srcdir:=${shell cd $(srcdir); pwd}
ifneq (,${filter-out /%,$(srcdir)})
    updir:=$(srcdir)/..
    updir1:=$(updir)/..
else
    updir:=${patsubst %:::,%,${patsubst %/:::,%,$(dir $(srcdir)):::}}
ifneq (,${findstring /,$(updir)})
    updir1:=${patsubst %:::,%,${patsubst %/:::,%,$(dir $(updir)):::}}
else
    updir1:=$(updir)/..
endif
endif

pwd:=${shell pwd}
ifneq "${filter winsup%,${notdir $(pwd)}}" ""
a:=${shell ${filter winsup%,${notdir $(pwd)}} >/dev/tty}
    here:=${pwd}/cygwin
else
a:=${shell ${filter winsup%,${notdir $(pwd)}} >/dev/tty}
    here:=${dir $(pwd)}cygwin
endif
bupdir:=${shell cd $(here)/..; pwd}
ifneq (,${filter-out /%,$(bupdir)})
    bupdir1:=../..
    bupdir2:=../../..
else
ifneq (,${findstring /,$(bupdir)})
    bupdir1:=${patsubst %:::,%,${patsubst %/:::,%,$(dir $(bupdir)):::}}
else
    bupdir1:=$(bupdir)/..
endif
ifneq (,${findstring /,$(bupdir1)})
    bupdir2:=${patsubst %:::,%,${patsubst %/:::,%,$(dir $(bupdir1)):::}}
else
    bupdir2:=$(bupdir1)/..
endif
endif

zlib_source:=$(updir)/zlib
zlib_build:=$(bupdir)/zlib
bz2lib_source:=$(updir)/bz2lib
bz2lib_build:=$(bupdir)/bz2lib
w32api_source:=$(updir)/w32api
w32api_build:=$(bupdir)/w32api
ifeq (,${findstring $(w32api_source),$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)})
w32api_include:=-I$(w32api_source)/include
endif
w32api_lib:=$(w32api_build)/lib
newlib_source:=$(updir1)/newlib
newlib_build:=$(bupdir1)/newlib
cygwin_build:=$(bupdir)/cygwin-daemon
cygwin_source:=$(updir)/cygwin-daemon
mingw_build:=$(bupdir)/mingw
mingw_source:=$(updir)/mingw
utils_build:=$(bupdir)/utils
utils_source:=$(updir)/utils
ifeq (,${findstring $(newlib_source)/libc/include,$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)})
newlib_include:=-I$(newlib_source)/libc/include
endif
ifeq (,${findstring $(newlib_source)/libc/sys/cygwin,$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)})
newlib_sys_include:=-I$(newlib_source)/libc/sys/cygwin
endif
ifeq (,${findstring $(newlib_source)/libc/sys/cygwin/include,$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)})
newlib_sys_include_include:=-I$(newlib_source)/libc/sys/cygwin/include
endif
ifeq (,${findstring $(cygwin_source)/include,$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)})
cygwin_include:=-I$(cygwin_source)/include
endif

INCLUDES:=-I. $(cygwin_include) -I$(cygwin_source) $(newlib_sys_include) $(newlib_include)  $(newlib_sys_include_include) $(w32api_include)
ifdef CONFIG_DIR
INCLUDES+=-I$(CONFIG_DIR)
endif

MINGW_INCLUDES:=-I$(updir)/mingw/include $(INCLUDES)

GCC_DEFAULT_OPTIONS:=$(CFLAGS_COMMON) $(CFLAGS_CONFIG) $(INCLUDES)

# Link in libc and libm from newlib

LIBC:=$(newlib_build)/libc/libc.a
LIBM:=$(newlib_build)/libm/libm.a
CRT0:=$(newlib_build)/libc/crt0.o

ALL_CFLAGS:=$(DEFS) $(MALLOC_DEBUG) $(CFLAGS) $(GCC_DEFAULT_OPTIONS)
ALL_CXXFLAGS:=$(DEFS) $(MALLOC_DEBUG) $(CXXFLAGS) $(GCC_DEFAULT_OPTIONS)

ifndef PREPROCESS
c=-c
o=.o
else
c=-E
o=.E
endif

libgcc:=${subst \,/,${shell $(CC_FOR_TARGET) -print-libgcc-file-name}}
gcc_libdir:=${word 1,${dir $(libgcc)}}
ifeq (,${findstring $(gcc_libdir),$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)})
GCC_INCLUDE:=-I$(gcc_libdir)/include
endif

COMPILE_CXX:=$(CXX) $c -nostdinc++ -nostdinc $(ALL_CXXFLAGS) $(GCC_INCLUDE) \
	     -fno-rtti -fno-exceptions
COMPILE_CC:=$(CC) $c -nostdinc $(ALL_CFLAGS) $(GCC_INCLUDE)

vpath %.a	$(cygwin_build):$(w32api_lib):$(newlib_build)/libc:$(newlib_build)/libm

MAKEOVERRIDES_WORKAROUND=${wordlist 2,1,a b c}

ifneq ($(MAKEOVERRIDES_WORKAROUND),)
    override MAKE:=$(MAKE) $(MAKEOVERRIDES)
    MAKEOVERRIDES:=
    export MAKEOVERRIDES
endif

ifdef RPATH_ENVVAR
VERBOSE=1
endif

ifneq "${findstring -B,$(COMPILE_CXX) $(COMPILE_CC)}" ""
VERBOSE=1
endif

.PRECIOUS: %.o

%.o: %.cc
ifdef VERBOSE
	$(COMPILE_CXX) -o $(@D)/$(*F)$o $<
else
	@echo $(CXX) $c $(CXXFLAGS) ... $(*F).cc
	@$(COMPILE_CXX) -o $(@D)/$(*F)$o $<
endif

%.o: %.c
ifdef VERBOSE
	$(COMPILE_CC) -o $(@D)/$(*F)$o $<
else
	@echo $(CC) $c $(CFLAGS) ... $(*F).c
	@$(COMPILE_CC) -o $(@D)/$(*F)$o $<
endif

$(bupdir1)/libiberty/%.o: $(updir1)/libiberty/%.c
	@$(MAKE) -C $(@D) $(@F)

$(w32api_lib)/%.a: $(w32api_lib)/Makefile
	@$(MAKE) --no-print-dir -C $(@D) $(@F)

$(bz2lib)/%.a: $(bz2lib)/Makefile
	@$(MAKE) --no-print-dir -C $(@D) $(@F)

$(zlib)/%.a: $(zlib)/Makefile
	@$(MAKE) --no-print-dir -C $(@D) $(@F)

all:

# For auto-rebuilding the Makefile

.PRECIOUS: Makefile

Makefile: Makefile.in $(srcdir)/configure.in config.status
	$(SHELL) config.status

config.status: configure
	$(SHELL) config.status --recheck


[-- Attachment #4: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: unix domain socket with shared memory ?

[Corinna Vinschen]

On Tue, Feb 12, 2002 at 02:07:52PM +0100, Ralf Habacker wrote:
> http://i30www.ira.uka.de/courses/winter00-01/Prosem_LinuxInternals/4.4ipc.ppt
> [...]

I'm somehow involved since I'm maintaining the socket code in Cygwin.
However, I will *not* read this posting since it's unreadable.  How
much useless stuff shall I read until something really important
happens?  Why is it so *damned* difficult to shorten mailings to
the relevant parts???

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: unix domain socket with shared memory ?

[Ralf Habacker]

>
> On Tue, Feb 12, 2002 at 02:07:52PM +0100, Ralf Habacker wrote:
> > http://i30www.ira.uka.de/courses/winter00-01/Prosem_LinuxInternals/4.4ipc.ppt
> > [...]
>
> I'm somehow involved since I'm maintaining the socket code in Cygwin.
> However, I will *not* read this posting since it's unreadable.  Ho
> much useless stuff shall I read until something really important
> happens?  Why is it so *damned* difficult to shorten mailings to
> the relevant parts???

Excuse me, I don't understand, what do you.
Do you mean that this link would be enough and the rest of the mail is useless or that this Power Point
presentation has so many useless pages for you ?

Ralf



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: unix domain socket with shared memory ?

[Corinna Vinschen]

On Tue, Feb 12, 2002 at 05:11:22PM +0100, Ralf Habacker wrote:
> Excuse me, I don't understand, what do you.
> Do you mean that this link would be enough and the rest of the mail is useless or that this Power Point
> presentation has so many useless pages for you ?

This PP presentation is completely useless to me since I don't
have PP.  I don't even understand what that has to do with the
thread.

But that's not the point.  Why is it needed to have the whole
thread again in the posting?  Could you please quote only the
relevant parts of previous postings?  I don't like to have to
scroll 400 lines down until the first new sentence occurs.
And perhaps it's possible to care for the line breakage.  I'm
tired to have to figure out first, which line is still part of 
the quote and which is new.

Just to be clear, you're not the only one and this happens not
only in this mailing list.  But that doesn't make it better.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: unix domain socket with shared memory ?

[Ralf Habacker]

[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Corinna Vinschen
> Sent: Tuesday, February 12, 2002 5:44 PM
> To: cygwin
> Subject: Re: unix domain socket with shared memory ?
>
>
> On Tue, Feb 12, 2002 at 05:11:22PM +0100, Ralf Habacker wrote:
> > Excuse me, I don't understand, what do you.
> > Do you mean that this link would be enough and the rest of the mail is useless or that this Power Point
> > presentation has so many useless pages for you ?
>
> This PP presentation is completely useless to me since I don't
> have PP.  I don't even understand what that has to do with the
> thread.

I'm sorry, I doesn't know that. You can find a viewer under
http://office.microsoft.com/germany/downloads/2000/Ppview97.aspx
This presentation is a journey of the linux tcp and unix domain socket implementation and show very nice how the
implementation works. An english translation is appended :-)
Perhaps we can use it to create soemthing similar for cygwin. I think there are only changes nesessary in the
functions names and functions levels, but the basics are the same.

Please be patiented with the presentation, I think the first pages will bore you, so skip to chapter 3, there are
the interesting thinks. I think this could be a good starting point for discussion. Especially for guys, who are
not very familiar with unix sockets (like I was)

> But that's not the point.  Why is it needed to have the whole
> thread again in the posting?  Could you please quote only the
> relevant parts of previous postings?  I don't like to have to
> scroll 400 lines down until the first new sentence occurs.

Okay, sorry.

> And perhaps it's possible to care for the line breakage.  I'm
> tired to have to figure out first, which line is still part of
> the quote and which is new.

I have no problem with line breakage. I have set line breakage to 115 characters, how do I set this ?

Currently I'm forced to use Outlook and this is very limited in the way of doing this.
Perhaps anyone else have an idea how to deal this with outlook.
I hope I can use KMail sometime in the future :-)

> Just to be clear, you're not the only one and this happens not
> only in this mailing list.  But that doesn't make it better.

Perhaps it would be good to give some hints, in the faq I haven't nothin about this topic ?

Ralf

[-- Attachment #2: unix socket.zip --]
[-- Type: application/x-zip-compressed, Size: 49219 bytes --]

[-- Attachment #3: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/