Mail Archives: cygwin-apps/2001/06/15/09:39:38
Hi!
Friday, 15 June, 2001 Ralf Habacker Ralf DOT Habacker AT saght DOT tessag DOT com wrote:
RH> I have applied the patch and as i see on short tests it works without
RH> errors. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
RH> Next week I think we have to figure out, whats going wrong
if you're to debug this yourself i can suggest you one more way to use
if running under strace dissolves the problem. you can change some of
debug_printf()s to system_printf()s -- they're printing things right
to the console.
i'd try to explain how things work (or at least supposed to work).
some application bind()s to a AF_UNIX socket. on cygwin, AF_UNIX
socket is a file of the following structire:
!<socket >port secret-cookie
where "port" is a AF_INET port used to emulate this socket and secret
cookie is some random 128-bit value.
when later application calls accept() on this socket, it creates
"server-side-secret-event". it's an event named
"cygwin.local_socket.secret.<port-number>.<secret-cookie>"
where port-number is local port number on which application accepts()
connection, and secret-cookie is that 128-bit value stored if socket
file.
Application that calls connect() is doing basically the same: it
creates "client-side-secret-event", named just like "server-side" one,
with only one exception -- port-number is a port from which connect()
is initiated.
now, everythig's ready and all client and server must do is to
"authenticate" each other. They're doing that by opening peer's secret
event (they can do it because they know both peer port and cookie),
signal it, and wait until peer signals their secret event. after that,
they proceed just like with normal socket connection.
Hope this explanation helps.
Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
- Raw text -