Date: Sun, 31 Jan 1999 00:47:42 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: howardjp@dragon.ham.muohio.edu (Jamie Howard) Cc: ckempf@enigami.com, freebsd-hackers@FreeBSD.ORG Subject: Re: socketpair(2) Message-ID: <199901310047.RAA27396@usr04.primenet.com> In-Reply-To: <Pine.LNX.4.05.9901301416450.12383-100000@dragon.ham.muohio.edu> from "Jamie Howard" at Jan 30, 99 02:26:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Right, but it seems as though a UNIX domain socket will allow a process to > read off the socket that which it has just written, when bidirectional, > correct? (Or am I doing something wrong?) Use two socketpair's. > It would be nice if two connected processes could send data back and > forth without reading off their own output, and a TCP connection > implements this. (I think this is similar to a channel under Plan 9/Alef, > but I do not know for certain due to lack of access.) Depending on these semantics is bad, even if you make it work in your particular kernel. > Have I missed something here? Your best bet would be to bind to 127.0.0.1, and use the standard bind/list/accept/connect to get real sockets over the loopback interface. If you had a dire need, you could name the function that encapsulated the whole process "socketpair". Since the connect won't complete until the accept, you will need to fork a child to call connect. If you were moderately insane, you'd set up a socketpair(2) to pass the descriptor back to the parent, and then make the child exit so that it looked like a single process function with a lump in it. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901310047.RAA27396>