I want to do followed thing.
Connect TCP socket in one process and work with it in another one.
It works fine if I fork second proc after connection establishing. But I need to to open sockets after fork().
I tried to use clone() with CLONE_FILES flag, it works. But clone() isn't POSIX api and it isn't supported by cygwin.

Is there another way to share sockets?

AFAIK it's not possible.
But, of course, you can open another socket to the same effect.

What do you mean: same effect.

I meant:
Sharinga descriptor to a socket would have effectively the same effect/result if you just open another socket and connect it to the same address.

Yes, sharing a socket between two processes *IS* possible.

You need to use a "Unix domain socket" to pass the descriptor from the process that opened the socket to the process that you want to share it. You'll also need some mechanism for synchronizing the two processes.

I'd strongly recommend this book:

Unix Network Programming, W. Richard Stevens, ISBN 0131411551

'hope that helps .. PSM

Can you elaborate on that ?
Unix domain sockets are a way to pass *data* from a process to another.
How would you pass the socket descriptor to the receiving socket, and how this destination process can make use of this descriptor ?

No, Unix domain sockets also permit you to pass *socket file descriptors* between processes.

The basic trick is to:

1. open a socket of type "AF_UNIX" (instead of the more common "AF_INET") in each process
2. Create a pipe to join the two sockets
3. Do a sendmsg() on the sender, and a recvmsg () on the process you want to share the socket

I did a brief Google search, and didn't find any URL's I could point you to.

But it does work - trust me.

And it's discussed in detail in the Stevens book I mentioned above.

'Hope that helps .. PSM

PS:
An equivalent technique is available on Windows: you need to do an OpenProcess() and a DuplicateHandle ().

Sorry, I'm still unconvinced, sendmsg and recvmsg are just another way to pass data, and anyway the issue is not passing something, but reusing it as a socket descriptor.

Too bad. You're mistaken.

Sendmsg and Rcvmsg are indeed a means of sending data. However, they can also be used as a means of "exporting" a file descriptor (such as a socket) from one process and making it a valid file descriptor in a different, otherwise unrelated process.

Why don't you look it up (or better, try it) yourself, and share with the group what you learn? I've used this technique on other Unix's (and Windows) in years past, but I've never had the opportunity to try it on Linux. I'm definitely curious what you find.

Your .. PSM

Sorry, but I'm not going to spend time to try to implement something I currently think is undoable.

You are the one suggesting this can work, but up to now haven't provide any evidence of it.

If you want to be trusted, show us it can be done.

If you really did it on Unix or Windows, please share that code/technique with us. This forum is not restricted to Linux.

1 members found this post helpful.

5 second Google search (consisting of keywords already listed above):

http://ldp.paradoxical.co.uk/HOWTO/S...O/sockets.html


http://lists.canonical.org/pipermail...ry/000292.html

http://www.research.att.com/~fenner/...s4_handout.pdf

http://www.cis.ksu.edu/~singh/CIS725...k_ipc_tut.html

etc etc

Okay, so your first search was less than 5 seconds ...
Anyway, sorry for not trusting you in the first time.
This is a very unadvertised feature.

I found some source code that shows how it can be implemented, and tried it under Solaris, it worked well.

Here's the link:
http://search.cpan.org/src/SAMPO/Soc...-0.03/passfd.c

Thanks

Hi -

My pleasure. And thanx for sharing link to the example code in Solaris!

Sincerely .. PSM

I'm also interested in this, read through the example sources and still am trying to understand.
So if the fd is created in one process, say has value 3, and it's passed to another process does it still have the value 3 when it is received?
Is a new fd created somewhere, duplicated or otherwise modified, that I'm not seeing, that will be valid in the new process? Just trying to figure this out.

The file descriptor number is different, but the underlying kernel structure seems to be shared, e.g. seeking the pointer on one side is seen on the other.