RE: unix domain socket with shared memory ?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]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 unix socket.zip Description: Zip compressed data -- 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 ?
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
RE: unix domain socket with shared memory ?
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 ?
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 Developermailto:[EMAIL PROTECTED] 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 ?
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
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.
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
-
HostOS Pipe AFTCP 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
TCPBRAMSCHE:4462 BRAMSCHE:0 ABHTREN
TCPBRAMSCHE:4464 BRAMSCHE:4462 WARTEND
TCPBRAMSCHE: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/
