Shared memory and IPC
wez at thebrainroom.com
Wed Sep 5 18:35:16 GMT 2001
On 05/09/01, "Rich Salz" <rsalz at zolera.com> wrote:
> I always found RPC towers -- the actual data structures that are created
> from string binding handles, like "ncadg_ip_udp:" -- hard to
> understand. The following OSF RFC might help a bit:
Luke: it says
"The unix protocol occupies the fourth floor of a DCE RPC tower. The left
side of the floor is the protocol identifier (0x20) and the right side is
a C string: a zero-terminated array of ASCII bytes. The value is the name
of the Unix-domain socket and must not exceed 108 bytes. "
> Here is an idea for how to do shared-memory IPC. A server that supports
> When the client wants to use shared-memory protseq it gets an endpoint
> that contains a filename (for use with ftok() and the server's local
> user id). So the string binding handle would look like this:
> ncadg_sm[id=0,ftok=/tmp/foo] (It's convenient that we only need two
> the permissions so that while it as creator has all perms, the owner is
> specified by the "id" and it also has all perms.
So the id is the uid of the owner.
Is that going to work for non-root apps? (I hope so!)
> Make sense? Lots of details to do, like having dced (er rpcd for old
> versions :) know how to clean up those endpoints. Since you typically
> can't select() on a sysv IPC sema or shared memory, you have to spawn a
> thread that sends messages back on a special internal loopback socket so
> select() knows what to do. per-fork cleanup. etc.
BTW: does dce1.2 dced do anything that dce1.1 rpcd can't do?
More information about the samba-technical