2

I have to write a program that serves multiple clients that access multiple resources (webcams) at the same time.

Example: clients A and B both asks for the current position of two pan-tilt cameras A and B. I have to avoid that the clients speak directly to that cameras (as there can be many clients) So my idea was to have a process for each client (who connects through a socket) and a process for each cam.

If a client requests the position for cam A the program forks new process for that cam, and that process polls the cam position repeatedly for 10 seconds and then exits. Within that 10 second period each position request from any client should be served by this cam-A process.

The problem is: How can the cam processes communicate with the client processes? My naive approach is the use of global variables (camA-posX, camA-posY, camB-posX, camB-posY,...) that the cam processes write to and the client processes read from. I even don't know if globals between forked processes are possible at all.

My second approach is to use pipes like in perlipc/Safe Pipe Opens but this only covers parent-child communication.

Another problem: There must be someone (the parent process?) who has to decide if I have to fork a new cam process or if it is still running.

Maybe it's even better to write two programs (using the second approach), one for the clients and one for the cameras, that communicates through a single socket with each other.

If the number of cams and clients raise there even might be a need of scaling the whole thing to distribute the load.

daxim
  • 39,270
  • 4
  • 65
  • 132
PaulS
  • 145
  • 1
  • 5
  • No, once the processes are forked, they no longer share memory space and therefore global variables are distinct between them. – DVK Jul 23 '13 at 16:05

1 Answers1

2

  • You can't use global variables. Once the processes are forked, they no longer share memory space and therefore global variables are distinct between them. You can only do this with threads, and using shared memory for communication needs to be done very carefully (as does anything in thread concurrent programming :)

  • For lower level IPC, use IPC::Msg

  • To be honest, if you need to worry about scaling, I would seriously recommend looking outside the IPC box, and using a real database to manage your communication.

    It can either be a relational database, or noSQL one, as long as it is one that guarantees transaction atomicity. mySQL should work perfectly fine.

  • Another similar approach (if DB is a bit of an overkill) is to use messaging queues, as discussed here: " A queueing system for Perl "

  • Some other solutions discussed:

Community
  • 1
  • 1
DVK
  • 126,886
  • 32
  • 213
  • 327
  • @mpapec - I haven't used it, but in general, if you care about scalability, go with MQ/DB instead of sockets/IPC. – DVK Jul 23 '13 at 16:27
  • Thanks DVK. MySQL and message queues both look promising. I will give them a try. Haven's thought at all about this kind of solution. – PaulS Jul 23 '13 at 18:13
  • The [use forks](https://metacpan.org/release/forks) module does allow you to share variables between forked processes. It's probably not an option you'd choose for performance though :-) – Grant McLean Jul 26 '13 at 00:33