This is the mail archive of the cygwin-developers mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On May 10 04:50, Lukas Haase wrote: > Hi, > > >From my application I would like to create ("export") a socket in > >native Windows API which can then be used by cygwin programs. > > I.e., if I would write the "server" in cygwin, Obligatory licensing hint: If you distribute your server outside your home or company, you're bound by the GPLv3 in terms of source code distribution. > I would use > socket(PF_LOCAL), select, read, write etc. However, I cannot use > cygwin because the application is developed in VC and C++ so I want to > emulate this functionality using only WinAPI functions. > > Socket files are just plain files containing stuff like: > > !<socket >54359 s 7B499653-622A1EB9-83E6B83E-A4E8D0C1 > > The first number is a port number as I understand, the 's' stands for > socket I guess No. 's' means SOCK_STREAM, 'd' means SOCK_DGRAM. > but what is the GUID number for? It's no GUID but just an array of 4 32 bit values, the AF_LOCAL "secret". Given that AF_LOCAL sockets are implemented using AF_INET sockets, there's a chance that a non-aware applicaton tries to connect to an AF_LOCAL socket. Therefore, the creator of the socket creates a "secret" and stores it in the socket file. When a AF_LOCAL-aware Cygwin application connects to this AF_LOCAL socket, it opens the file and reads the "secret". It can only do so if it has permissions to read the file. That's all there is for SOCK_DGRAM sockets. For SOCK_STREAM sockets, the connect/accept attempt starts with exchanging "secret" and credential packets between client and server. - Client sends the 16 byte "secret" to the server. - Server recvs the 16 byte "secret" and compares with its own "secret". - Server sends own 16 byte "secret". - Client recvs and compares with its own "secret". If any of the above fails, the peers close their side of the socket and return with errno set to ECONNABORTED (accept) or ECONNREFUSED (connect). The secret exchange makes sure that the peers both are on the same side. They know of AF_LOCAL sockets, they have the permissions to open the socket, and the client and the server are actually using the *same* AF_LOCAL socket. If the secret exchange succeeded, two more packets are exchanged: - Client sends packet with credential data. - Server answers with credential packet. A credential packet looks like this: struct ucred { pid_t pid; uid_t uid; gid_t gid; }; These are Cygwin pid, uid, and gid, of course. The data is used to implement getpeereid() and getsockopt(s, SOL_SOCKET, SO_PEERCRED, ...). HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpMs8Z10K_FI.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |