message passing question

[proxy]

OK, I have a basic message based IPC system in my OS. It's pretty simple for the time being, my API consists of:

void openport(int port);
void closeport(int port);
void sendmessage(pid, port, buf, size);
void recvmessage(port, buf, size);

messages are fixed size (size of buf is some values <= max message size) and sent to a "port" associated with a given pid. then the process does a recv on that port, which will block until a message arrives.

It works quite reliably. Here's my problem. How does the sender know the pid of the process it wants to send to. I have been trying to think of a nice clean API for this and can't really think of anything good.

What do other people here? I was thinking perhaps a system call where you can ask the sytem which pids have open ports and a string representing the "service" they offer on that port (this way both the client and server can agree on a service name).

any thoughts?

proxy

[JamesM]

Personally I use RMI (remote method invocation) but the theory is the same: My kernel maintains a table of strings (describing services) to Objects (in your case it would be pids).

Alternatively you can go the linux route and have your process write it's pid to a file in a standard location. C.f. "/var/run/mysql.sock".

[Brendan]

Hi,

Personally I use RMI (remote method invocation) but the theory is the same: My kernel maintains a table of strings (describing services) to Objects (in your case it would be pids).

Alternatively you can go the linux route and have your process write it's pid to a file in a standard location. C.f. "/var/run/mysql.sock".

Or, you could do both - use the kernel's table for speed, and make the VFS map this table into the virtual file system somewhere (e.g. "/proc/ports/") to make it easier for scripting.


Cheers,

Brendan

[nooooooooos]

Why not use Strings for PIDs? It's very easy...

Cheers

[JamesM]

Why not use Strings for PIDs? It's very easy...

What are you on about? I do not class that as either an answer nor an explanation.

[jal]

messages are fixed size (size of buf is some values <= max message size) and sent to a "port" associated with a given pid. then the process does a recv on that port, which will block until a message arrives.

It works quite reliably. Here's my problem. How does the sender know the pid of the process it wants to send to. I have been trying to think of a nice clean API for this and can't really think of anything good.

How does the sender know there are other processes at all? How does a sender know whom he wants to send to? You either want to send something to threads or processes spawned by you (or your parent, or your siblings, or your uncles, aunts, cousins, nephews and nieces, in various removedness and degree, you get the point), in which case there's probably some internal data structure you can use (e.g. when doing a POSIX fork, the child's pid is returned, and presumably stored). If you want to send something to a process or thread that's not under your control, then that would either be someone who wants something from you (i.e. you are some sort of service), in which case he contacted you first (and you have stored his pid), or you want something from a service, in which case the OS must have some kind of API to retrieve a service's pid, so you can sent to it. Otherwise I see no reason to send someone something, but surely your OS must have some kind of 'process/thread overview' API or file or whatever you can then use.


JAL

[proxy]

well the most common reason I can think for "unrelated" processes to send messages to each other is when you have one that offers a service that any process may want to use.

My prime example would be my user space GUI code. I want my graphics server to be an application that any process can send messages to to say "hey, i would like to draw an object at (x,y) with this shape, size" and be able to receive messages for events.

proxy

[jal]

well the most common reason I can think for "unrelated" processes to send messages to each other is when you have one that offers a service that any process may want to use.

My prime example would be my user space GUI code. I want my graphics server to be an application that any process can send messages to to say "hey, i would like to draw an object at (x,y) with this shape, size" and be able to receive messages for events.

Exactly, so that's a service. And either services must have some form of standard name you can use, or the OS must have some API to get the name of a certain type of server. So that's where you get your PID from.


JAL

[distantvoices]

Or you use some kind of bus system to transfer messages from A to B. something like DBUS.

I have implemented a service dictionary which one can ask to obtain the process id for a wellknown service - in order to send a message forth.