Thread: Problem with named FIFO

Originally Posted by kbzium

The server must surely have some shared memory for it's subproccesses to communicate - but what would be the best - PIPE or unnamed PIPE?

It must use some form of IPC -- eg, shared memory OR pipes. What are the subprocesses for? Are you going to fork every client?

That may not be necessary (unless it is specifically part of the assignment); you could also use non-blocking sockets and queue/buffer data. Even with dozens and dozens of connections, the effect can be made seamless; tcp/ip is not really a steady stream anyway (plus think where forking dozens of clients is going to take you...).

But, since you have to use sockets for the tcp connections, if you do use multiple processes, why not use tcp/ip sockets with them too? They are somewhat less hassle and more flexible than pipes. Linux has "unix local" sockets for stuff like this, they are probably the most common form of IPC.

Originally Posted by kbzium

Yes, i use subprocesses to handle each client individually. That's the way they did it in classes so i did it to and i'd rather do it that way even if that may be not the best way to do it.

It's not unusual; most mainstream http servers use a variation on this theme. But there are hard limits on how many connections they will really maintain simultaneously, and limits on how long they will maintain them (generally, <20 seconds).

Presuming your connections are more persistent, you should check how many you have to maintain; while in theory forking does not have a limit, in practice it uses a lot of memory, is the issue. But I imagine for this it is not such a serious one.

The thing is that as for communication stuff it works (the server accepts clients and talk with them), but i can't manage to make the server talk to everyone at once (if a client posts new message).

If each client is in it's own fork, you have to pass the message from that process to the parent-server process, and then the parent passes it on to all it's children. To do that you need to use some form of IPC (Inter Process Communication):

Inter-process communication - Wikipedia, the free encyclopedia

Shared memory is something that is also called unnamed pipe?

Pipes and shared mem are two different means of accomplishing IPC.

I wouldn't use shared mem unless you've used it before because it will require locking, which is a lot of new stuff to cram into one assignment. Like I said, I'd just use sockets for the whole thing, since you have to use sockets for the client connections anyway. So each fork would have two sockets to handle, one to the client and one to the server. Sounds redundant at first, but if the fork mostly handles the client on it's own, this frees up the parent-server, and in any case the parent<->child connections will be local, so the child forks will be a kind of buffer between the parent-server and the clients. If one of the client connections is slow, it won't affect the server-parent as much as it will affect the child fork.

I'd rather not change my entire code...

I don't know if you have to, but if you do, sooner is better than later.

Posting your code always helps. There is no guarantee anyone will read it all, of course, but as long as it is indented, don't worry about polish.