From: Chris Friesen <cfriesen@nortelnetworks.com>
To: Terje Eggestad <terje.eggestad@scali.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com
Subject: Re: anyone ever done multicast AF_UNIX sockets?
Date: Mon, 03 Mar 2003 17:29:14 -0500 [thread overview]
Message-ID: <3E63D73A.2000402@nortelnetworks.com> (raw)
In-Reply-To: 1046720360.28127.209.camel@eggis1
Terje Eggestad wrote:
> On Mon, 2003-03-03 at 18:09, Chris Friesen wrote:
> Terje Eggestad wrote:
> > On a single box you would use a shared memory segment to do this. It has
> > the following advantages:
> > - no syscalls at all
>
> Unless you poll for messages on the receiving side, how do you trigger
> the receiver to look for a message? Shared memory doesn't have file
> descriptors.
>
> OK, you want multicast to send the *same* info to all peers. The only of
> two sane reason to do that is to update the peers with some info they
> need to do real work. So when there is reel work to be done, the info is
> available in the shm.
Okay, but how do they know there is work to be done? They're waiting in
select() monitoring sockets, fds, being hit with signals, etc. How do
you tell them to check their messages? You have to hit them over the
head with a signal or something and tell them to check the shared memory
messages.
> If you *had* multicast, you don't know *when* a peer proccessed it.
> What if the peer is suspended ??? you don't get an error on the send,
> and you apparently never get an answer, then what? The peer may also
> gone haywire on a while(1);
Exactly. So if the message got delivered you have no way of knowing for
sure that it was processed and you have application-level timers and
stuff. But if the message wasn't delivered to anyone and you know it
should have been, then you don't have to wait for the timer to expire to
know that they didn't get it.
> How do they know the information has changed? Suppose one process
> detects that the ethernet link has dropped. How does it alert other
> processes which need to do something?
>
> Again, if you want someone to do something, they must ack the request
> before you can safely assume that they are going to do something.
Certainly. My point was that if you're trying to handle all events in a
single thread, you need some way to tell the message recipient that it
needs to check the shared memory buffer. Otherwise you need multiple
threads like you mentioned in your project description.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com
next prev parent reply other threads:[~2003-03-03 22:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-27 20:09 anyone ever done multicast AF_UNIX sockets? Chris Friesen
2003-02-27 22:21 ` Greg Daley
2003-02-28 13:33 ` jamal
2003-02-28 14:39 ` Chris Friesen
2003-03-01 3:18 ` jamal
2003-03-02 6:03 ` Chris Friesen
2003-03-02 14:11 ` jamal
2003-03-03 18:02 ` Chris Friesen
2003-03-03 12:51 ` Terje Eggestad
2003-03-03 12:35 ` David S. Miller
2003-03-03 17:09 ` Chris Friesen
2003-03-03 16:55 ` David S. Miller
2003-03-03 18:07 ` Chris Friesen
2003-03-03 17:56 ` David S. Miller
2003-03-03 19:11 ` Chris Friesen
2003-03-03 18:56 ` David S. Miller
2003-03-03 19:42 ` Terje Eggestad
2003-03-03 21:32 ` Chris Friesen
2003-03-03 23:38 ` Terje Eggestad
2003-03-03 19:39 ` Terje Eggestad
2003-03-03 22:29 ` Chris Friesen [this message]
2003-03-03 23:29 ` Terje Eggestad
2003-03-04 2:38 ` jamal
[not found] <3E5E7081.6020704@nortelnetworks.com.suse.lists.linux.kernel>
[not found] ` <20030228083009.Y53276@shell.cyberus.ca.suse.lists.linux.kernel>
[not found] ` <3E5F748E.2080605@nortelnetworks.com.suse.lists.linux.kernel>
[not found] ` <20030228212309.C57212@shell.cyberus.ca.suse.lists.linux.kernel>
[not found] ` <3E619E97.8010508@nortelnetworks.com.suse.lists.linux.kernel>
[not found] ` <20030302081916.S61365@shell.cyberus.ca.suse.lists.linux.kernel>
[not found] ` <3E6398C4.2020605@nortelnetworks.com.suse.lists.linux.kernel>
2003-03-03 18:18 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E63D73A.2000402@nortelnetworks.com \
--to=cfriesen@nortelnetworks.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=terje.eggestad@scali.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).