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/