Again, In reference to this post of mine deep in a Projects thread, I thought that this question would be better asked here.

What is the best way to communciate between processes? I was going to start out using named pipes, but reading a bit more, message queueing seems nice too, although with more code. I really only need to have one-way communcation, so fifo's would be all I need, but from a style aspect, should I go ahead and learn how to use message queues?

I suggested using IPC for sharing the GPS data, but got the reply that IPC is not supported in the stock or Hijack kernel and there was a hint that IPC contained a little more bloat than was prefered.

message queues (sysV at least) aren't in compiled into the kernel (or hijack). Easy enough to do however. Posix messages queue should be possible, but the arm librt doesn't appear to have the library functions (also from looking at the code, posix and sysV stuff seems to be in the same .c file so I would imagine you still need sysV).

Ok, well that limits me to named pipes, then. I'll move forward working on that.

Sorry about that, I feel like I am having a "rain on peoples parade" day, as I have shot down about 4 outstanding ideas at work too

Well, just plain pipes will work too -- especially convenient when one process starts up the others. It can just redirect stdin/stdout/whatever before forking.

-ml

Shooting down ideas used to be much more common on this board... then a few of us started ignoring such comments, and produced Hijack, the webserver, the ftpserver, tons of apps, etc..

On the whole, I think the naysayers number fewer than they did here 18 months ago. Somebody has to fill in for them!

Cheers!

My process won't start up the others, and they may or may not be running, that's why I was thinking of using named pipes. Basically, each pipe would be used to handle different OBEX objects coming in over IrDA. Objects with .txt extensions would be redirected to the /somedir/empire.text named pipe, .vcd would be /somedir/empire.address, .empeg would be /somedir/empire.control, etc. Then if the OBEX listener (empire) recieves a .txt file, and the /somedir/empire.text has not been opened for reading, we would discard the object. If there is a listener attached, then we would output the contents of the file to the pipe.

I plan to have a listener on /somedir/empire.control that will take .empeg OBEX objects and redirect them to the player app over the serial port.

Does this sound like it would work correctly?

Named UNIX domain sockets would probably be the best thing for you to use, but, IIRC, they require a writable filesystem (because you can't precreate the files like you do with named pipes; they get created at runtime), which we don't have in the empeg environment.

is there any room on the scratch partition? I guess we don't know the complete format of it...

I would just go with regular tcp sockets. The only thing that is missing is 'ifconfig lo up'. When I get some time I'll figure out the necessary ioctls, or borrow them from busybox or some other minimally sized app. Once the loopback device is up, it is just a matter of binding to 127.0.0.1 port foo, and accepting incoming client connections.

We know that the empeg has a full network stack already, otherwise tcp over the ethernet cable wouldn't work.

How about using an agreed-upon socket (port number) for listen()ing on, and then just structure the code like any other networking server code -- fork the socket/process on connect, parent listens for more connections, child services the current connection/request(s).. As a side benefit, this allows the client/server to be on different network nodes if ever desired, like during testing..

?

I'd originally suggested fifos without puting a whole lot of thought into it. With Cushman's comment above about what happens when the listening process isn't running (IIRC, you just block for writing indefinintely?).

TCP sockets on the real interface sounds like an excellent idea... I like the being able to connect from other machines aspect.

What happens if the player's in DHCP mode and you're in-car? Is the interface still brought up just without an IP or is it down? Can you bind to it?

In reply to:

---

How about using an agreed-upon socket (port number) for listen()ing on, and then just structure the code like any other networking server code -- fork the socket/process on connect, parent listens for more connections, child services the current connection/request(s).. As a side benefit, this allows the client/server to be on different network nodes if ever desired, like during testing..

---

That sounds much cleaner than using named pipes! I've never done socket programming before, but reading up on it right now it seems to me like this is the way to go. Let me see if I have the concepts right. I would write a server that would listen in on a certain TCP port (looking at an /etc/services file I should choose one between 49152 and 65535) and handle multiple connections to this port by clients. I wouldn't have to have the interface lo up, since I could just connect to the address 0.

The program woudl fork() when a client is connected. How would I ensure that the IrDA port is only read by one process? I don't think that the IrDA port is able to be read from by more than one process at a time. The clients could filter out any objects other than the ones they are listening for, but I'm unsure how to make the server output the incoming OBEX object to all fork()'ed processes.

Any suggestions?

There's (normally) also a "loopback" interface, so daemons usually just bind to the same port number, irrespective of the interface. This allows them to be accessed locally within the same machine, as well as remotely if/when the ethernet (or usb-eth or ppp or ...) interface(s) come alive. No fuss, simple to do.

Cheers

The IRDA port should perhaps have a single master server process associated with it, which then re-broadcasts all incoming data to whomever wants to listen to it. You can come up with a half dozen ways to structure that code, using notify lists or a tree of subservers or whatever. Any app that wants IRDA data just connects to the master server rather than the device itself.

Keep reading.. lots of good books and good code examples exist on servers that use this general connection method. Heck, even Hijack has it in-kernel for khttpd and kftpd.

-ml

In reply to:

---

With Cushman's comment above about what happens when the listening process isn't running (IIRC, you just block for writing indefinintely?).

---

Actually if there was not a listener on the named pipe, then you would skip writing to it and discard the object. Blocking wouldn't make too much sense in that area ;-) If nobody is listening, why bother saying anything?

Thanks, Mark! I have a two QUE books on Linux Programming and Linux Socket Programming. Are there any others that you would suggest, or any websites you could refer me to? I will take a look at your code in kftpd.c and see what I can glean from there. It seems to me that the examples in the QUE books all use IPC functions to communicate between processes in a multi-client server.

Isn't it funny that there are 1001 books on basic programming (printf and if-then-else) but there are very few on overall programming concepts?

Okay, there are the books you need:

"Advanced Programming in the UNIX Environment"
by W. Richard Stevens 1992 Addison-Wesley
ISBN 0-201-56317-7

"TCP/IP Illustrated Volume 2"
by Gary R. Wright, W. Richard Stevens 1995 Addison-Wesley
ISBN 0-201-63354-X

"UNIX Network Programming Volume 1"
by W. Richard Stevens 1998 Addison-Wesley
ISBN 0-13-490012-X

"UNIX Network Programming Volume 2"
by W. Richard Stevens 1999 Addison-Wesley
ISBN 0-13-081081-9

Unfortunately, the author (Stevens) was killed in a car crash a year or two ago, so this former font of practical information is no more.

Cheers

Actually, scratch the "UNIX Network Programming Volume 2" -- nice to have, but not as useful here as Volume 1.

If you can only buy one book, get that Volume 1.
But the "Advanced Programming in the UNIX Environment" book is almost essential for lots of stuff too.

Cheers

EDIT: had vol 1/2 reversed here originally.. oops

Unfortunately, the author (Stevens) was killed in a car crash a year or two ago, so this former font of practical information is no more.

The company I was working for at the time had a one-minute network outage as a mark of respect.

Peter

Source attached.

And here's the binary. 3k, stripped.