Xref: utzoo comp.unix.questions:29481 comp.unix.internals:2344
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.questions,comp.unix.internals
Subject: Re: Multiprocessing via sockets
Message-ID: <1991Mar15.101603.13968@thunder.mcrcim.mcgill.edu>
Date: 15 Mar 91 10:16:03 GMT
References: <4306@skye.ed.ac.uk> <1991Mar13.053500.17782@neon.Stanford.EDU>
Organization: McGill Research Centre for Intelligent Machines
Lines: 31

In article <1991Mar13.053500.17782@neon.Stanford.EDU>, sidana@neon.Stanford.EDU (Ashmeet S Sidana) writes:
> In article <4306@skye.ed.ac.uk> rbs@bute.ed.aiai (Robert Scott) writes:
>> I want to generalise the system.  I want an unlimited number of
>> machine to be able to communicate.  I can see that on each machine I
>> need to create an array of sockets of length N (the number of
>> machines) so that each machine can talk directly to any other.
> If your communication requirements are not too high then you could
> just communicate through one socket (with everybody listening),
> whereby the first byte would indicate which machine the message was
> for (assuming < 255 machines)

Um, just how does one do this?  A socket can be connected to at most
one peer.

The only case where I can see this being of any use is when using
connectionless protocols like UDP, all machines involved are on a
common network, and that network supports broadcasting.  And as far as
I know, all connectionless protocols implemented are unreliable, in
that your packet may get dropped without notice.  (Of course, the
common network and broadcast restrictions may be relaxable in an
environment with multicasting available.  But if you're doing research
like that into networking, you don't have to post networking questions
like this.)

Of course, if that's OK for your application, go ahead. :-)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu