jordan@greipa.UUCP (Jordan K. Hubbard) (05/28/85)
[ Also posted to su.unix.wizards ]
Hi.
Can several processes write to a unix-domain stream socket at the
same time and preserve the 'atomic' nature of each call? (say two
processes wrote out a 7 byte structure to the same socket, could
this become garbaged?) Should I be using datagram sockets?
Even more important to this discussion, can several processes write
to a socket without 'connecting' to it? I.E. calling socket and
binding the descriptor to an existing socket (unix file) then reading/
writing directly to the socket without calling connect. The reason
being that I need to server to go into a read wait on a socket
for data that could come from several processes at different times.
I'd like to give each process its own socket in the usual way, but
that means I'd have to go into an accept wait, and I want to be
able to respond to data sent by earlier processes more or less immediately.
(The number of processes communicating with the same server is arbitrary,
but they're all related and need to access one set of data known to
the server)
If there's a decent way of doing this and I'm too thick/ignorant
to realize it, I'd welcome any suggestions..
Thanks.
--
Jordan K. Hubbard
@ Genstar Rental Electronics.
Palo Alto, CA.
{pesnta, decwrl, dual, pyramid}!greipa!jordan
"Ack ack!".
- William the felinerst@tardis.UUCP (Robert Thau) (05/29/85)
> The reason > being that I need to server to go into a read wait on a socket > for data that could come from several processes at different times. > I'd like to give each process its own socket in the usual way, but > that means I'd have to go into an accept wait, and I want to be > able to respond to data sent by earlier processes more or less immediately. If a server socket is select(2)ed for read, the select will return with "data available" on the server when a peer tries to connect. You can then accept() without the wait, since you already know someone's connecting. Since there's probably a select() in your main loop anyway, this is the way to go. The 'pwrite' multi-way talk program which was posted to net.sources a while ago worked like this; you might want to take a look. (No flames... there's nothing wrong with pwrite that a sed script won't fix). BTW, AF_UNIX is a bit flaky; although ordinary stream sockets do work, out-of-band data and datagrams may or may not make the system go away (depending on the phase of the moon and the patches that have been applied at your site). Internet sockets have a few advantages besides; they make your program work intermachine with less work, and they make cleanup on abnormal exit easier (nothing to unlink). Robert Thau rst@tardis.ARPA
chris@umcp-cs.UUCP (Chris Torek) (05/29/85)
> Can several processes write to a unix-domain stream socket at the > same time and preserve the 'atomic' nature of each call? Yes, if you're lucky. > Should I be using datagram sockets? Probably. > Even more important to this discussion, can several processes write > to a socket without 'connecting' to it? I.E. calling socket and > binding the descriptor to an existing socket (unix file) then reading/ > writing directly to the socket without calling connect. The reason > being that I need to server to go into a read wait on a socket > for data that could come from several processes at different times. > I'd like to give each process its own socket in the usual way, but > that means I'd have to go into an accept wait... (Ignoring the fact that that AF_UNIX SOCK_DGRAMs are connectionless...) Not true; you can use select to tell you which of the r/w sockets and/or the original bound socket are ``readable''. Select for reading succeeds when the accept() system call will not block. This is well-known in a couple of servers and isn't likely to change.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland