Shared memory and IPC

[Wez Furlong]

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:[135]" -- hard to
> understand.  The following OSF RFC might help a bit:
> http://www.opengroup.org/rfc/rfc81.2.html

Ahh.
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.

Sounds reasonable.
Thanks!

BTW: does dce1.2 dced do anything that dce1.1 rpcd can't do?

--Wez.