Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Apr 1997 16:02:02 -0700 (PDT)
From:      batie@agora.rdrop.com (Alan Batie)
To:        hackers@freebsd.org
Cc:        batie@aahz.jf.intel.com
Subject:   setsockopt vs fork
Message-ID:  <m0wKu0A-0009DEC@agora.rdrop.com>

next in thread | raw e-mail | index | archive | help
I'm porting a packet analyzer program which does the following:

open socket
fork and call event scheduler routine
fork and call packet receiver routine
log status messages from the two children

the scheduler, according to a script file, joins and leaves multicast
groups using setsockopt on the socket created by the parent.  Actually,
if it gets too many groups for the socket (as defined by a #define limit;
comments indicate this is to workaround a problem on SGI's), it opens a
new socket for the additional groups.  As script events occur, status
messages are sent to the parent.

The packet receiver process just reads packets from the socket and sends
status messages to the parent.

My question is: is it a valid assumption to make that setsockopt in one
process will affect the socket in another given that they have common
origins?  It is fork and not vfork being used...

I haven't yet figured out how he expects the receiver to know about any
*new* sockets he creates, so maybe there's something I'm missing, but I
sure don't see see any communication mechanism and I'm not creating that
many groups anyhow, but it's definitely *not* seeing the multicast packets
I'm sending to it...

Thanks for any help...

-- 
Alan Batie                   ______      It's not my fault!  It's some guy
batie@agora.rdrop.com        \    /      named "General Protection"!
+1 503 452-0960               \  /       --Ratbert
PGP FP: DE 3C 29 17 C0 49      \/        7A 27 40 A5 3C 37 4A DA 52 B9

It is my policy to avoid purchase of any products from companies which
use unrequested email advertisements or telephone solicitation.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0wKu0A-0009DEC>