vijay@nixdorf2.osf.org (Vijay Kumar) (02/20/91)
Hi, I have some questions concerning MACH. 1. I am having difficulty in understanding the MACH object-oriented construction of distributed systems. The no-senders detection mechanism lets servers detect receive ports for which there are no senders. Of what use is such a detection mechanism? 2. In the article that I was reading, the authors also say that the mechanism significantly reduces the number of ports used by object-oriented servers, because they do not need to create a notify port for every object port. Clients holding send rights for the object port can not forge no-senders notifications, because the server can distinguish messages sent to send rights. This totally confuses me. Can someone throw some light on this topic? 3. I have a very sketchy idea about netmsgservers How would a client initiate communication with a remote server and reliabaly transfer data? Various steps are involved before a client start communicating with a server, like a lookup operation with a nameserver or the netmsgserver itself provides some sort of lookup operation. Then what kind of lookup can a client perform (object name, portname, server name, ......????) What are proxy ports? 4. Servers can abort computations on behalf of a dead client by requesting dead-name notifications for the send-once right reply port. In what way is this dead name notification of any importance to the server because it will receive the notification only after the computation completes and also the next thing that a server does (before it receives the dead-name notification) will be to send a reply on the send-once right reply port and it will know about the client's death at that time. The dead-name notification is of no use to the server unless the kernel pre-empts the server and the server does some sort of a stack-rewind operation after it realizes that the client is dead. 5. The new IPC mechanism implemented in Mach 3.0 uses copy-on-write optimization. Basically, when a client task sends a message to a server, the physical pages which contain the client's message are mapped into the server's unused virtual address space. That way, a copy operation is saved and the kernel changes the protection of the shared pages so the a protection violation fault gets kicked of if either one of them modifies data. But later I also read that a send operation has two phases. First, the kernel copies the message into an internal buffer, making out-of-line memory regions copy-on-write. Now why do we need to make the memory regions copy-on-write after it is being copied anyway? I also thought we are avoiding a copy operation, but actually we are not.. 6. Do send and receive ports have two different names? Is the port name some thing like a file descriptor? Thanks in advance. Vijay (vijay@osf.org)
mib@geech.ai.mit.edu (Michael I Bushnell) (02/20/91)
In article <19089@paperboy.OSF.ORG> vijay@nixdorf2.osf.org (Vijay Kumar) writes:
Path: mintaka!snorkelwacker.mit.edu!paperboy!nixdorf2.osf.org!vijay
From: vijay@nixdorf2.osf.org (Vijay Kumar)
Newsgroups: comp.os.mach
Date: 19 Feb 91 21:03:07 GMT
Sender: news@OSF.ORG
Reply-To: vijay@nixdorf2.osf.org (Vijay Kumar)
Lines: 69
1. I am having difficulty in understanding the MACH
object-oriented construction of distributed systems.
The no-senders detection mechanism lets servers detect
receive ports for which there are no senders. Of what
use is such a detection mechanism?
Servers may want to deallocate resources when they are no longer in
use. The no senders notification allows server to detect this. Think
of the kernel keeping a reference count for each send port, and
telling the server when the ref count drops to zero.
2. In the article that I was reading, the authors also say
that the mechanism significantly reduces the number of
ports used by object-oriented servers, because they do
not need to create a notify port for every object port.
Clients holding send rights for the object port can not
forge no-senders notifications, because the server can
distinguish messages sent to send rights.
This totally confuses me. Can someone throw some light
on this topic?
I don't understand this either. Perhaps if you posted a quote from
the article?
4. Servers can abort computations on behalf of a
dead client by requesting dead-name notifications for the
send-once right reply port. In what way is this dead name
notification of any importance to the server because it
will receive the notification only after the computation
completes and also the next thing that a server does
(before it receives the dead-name notification) will
be to send a reply on the send-once right reply port and
it will know about the client's death at that time. The
dead-name notification is of no use to the server unless
the kernel pre-empts the server and the server does some
sort of a stack-rewind operation after it realizes that
the client is dead.
There are usually several threads within a server. One may be
dedicated to receiving the dead-name notification and then stopping
the thread processing the request. With a single threaded server, the
notificiation is certainly of less value.
5. The new IPC mechanism implemented in Mach 3.0 uses
copy-on-write optimization. Basically, when a client
task sends a message to a server, the physical pages
which contain the client's message are mapped into
the server's unused virtual address space. That way,
a copy operation is saved and the kernel changes the
protection of the shared pages so the a protection violation
fault gets kicked of if either one of them modifies data.
But later I also read that a send operation has two
phases. First, the kernel copies the message into
an internal buffer, making out-of-line memory regions
copy-on-write. Now why do we need to make the memory
regions copy-on-write after it is being copied anyway?
I also thought we are avoiding a copy operation, but
actually we are not..
When it says "copies into an internal buffer" it means the message and
the pointer, but not the out-of-band data itself.
6. Do send and receive ports have two different names?
Is the port name some thing like a file descriptor?
No. If a task has send rights and receive rights for the same port,
the two rights share the same name. A port name is somewhat like a
file descriptor, except they are arbitrary 32 bit numbers instead of
small integers.
-mibRichard.Draves@cs.cmu.edu (02/22/91)
> Excerpts from netnews.comp.os.mach: 19-Feb-91 MACH questions.. Vijay > Kumar@nixdorf2.osf (2876) Michael Bushnell already answered questions 1, 4, 5, and 6. > 2. In the article that I was reading, the authors also say > that the mechanism significantly reduces the number of > ports used by object-oriented servers, because they do > not need to create a notify port for every object port. > Clients holding send rights for the object port can not > forge no-senders notifications, because the server can > distinguish messages sent to send rights. > This totally confuses me. Can someone throw some light > on this topic? The server wants to get a no-senders notification for an object port. It needs to give the kernel a send-once right to a notify port. The kernel will send the no-senders notification to the send-once right. The server doesn't need to allocate a separate notify port; it can give the kernel a send-once right to the object port itself. Two things make this work. First, the existence of the send-once right doesn't inhibit the no-senders notification. No-senders notifications only apply to send rights. Second, clients (who hold send rights for the object port) can't forge a no-senders notification, because the receiver of a message can tell if it was sent to a send right or a send-once right. > 3. I have a very sketchy idea about netmsgservers > How would a client initiate communication with a remote > server and reliabaly transfer data? Various steps are > involved before a client start communicating with a > server, like a lookup operation with a nameserver or > the netmsgserver itself provides some sort of lookup operation. > Then what kind of lookup can a client perform (object name, > portname, server name, ......????) What are proxy ports? The netmsgserver exports a simple name service. When a client on machine A looks up a server on machine B, the netmsgserver on A creates a port that is the local representative on A of the server's port (which exists on B). This representative is called a proxy port. The name service returns to the client a send right for the proxy port, which the client will use to communicate with the server. The client doesn't realize (and can't realize) that it is actually using the proxy port to send messages to the netmsgserver on A, which forwards them to B, instead of sending messages directly to the server on B. Rich
slone@sctc.com (Brent Slone) (04/02/91)
I have a few basic Mach questions. Some are quite simple so please bear with me. 1. Please explain the nature of the use of VM_COPY, VM_READ, and VM_WRITE between tasks. What exactly are they for and some examples of contexts where these services are perceived to be good solutions to a problem. 2. Exactly when does an external pager get into play in detemining access rights on an external object? For example if Task A has a file, external object, mapped into its address space, and it wants to copy a page from that object to another tasks address space, will the external pager be asked to verify the read write privileges of the receiving task on that object? Similar but related question, if a Task A has an external object open and sets it's inheritance attributes to share, and then creates a new process is there any check to revalidate the access privileges to that object for the new task? 3. When a task maps an external object into its address space, when do the access privileges for that task to that object get set and by who? 4. From a Mach Unix process calling "creat" and later "write", could you trace the sequence of calls between the file system server, mach kernel, pager, device driver, etc? 5. Is the default pager part of the kernel, ie. does it run with kernel view of resources and address map? What about user-defined pagers? What about device drivers? Thanks, Brent Slone slone@sctc.com