Hi,
Basically I've written a game in ncurses that supports multiple players. Each player has a process associated with him which shares a segment of memory in which the player's structures are stored, and these structured are accessed by the 'server' program and handled there. The scope of the program is that when a user wants to access a game that has already started he can do so from his terminal, and the 'server' process will simply fork a child process to handle his input and start communicating with it. I am having problems implementing this. Is there a way to have the server listen for commands that can come from a seperate terminal such that when this command is invoked it performs a specific routine ? Thanks. Any help will be appreciated.
This is mostly a networking problem. How familiar are you with TCP networking? You could also do this through UNIX domain sockets but you could just as easily substitute TCP sockets and get a game server that can work over the internet. 
The jist of it is, have a thread in your server waiting for connections such that, when accept() returns, the server forks off a new process to handle the new connection.
If you have shared memory, why does the server need to handle the input?
The client process writes and reads shared memory. What else is needed?
Correct me if I'm wrong but it sounds to me like the shared memory is all part of the server and not relevant to the clients. The server forks off its own processes to handle the game space.
[edit] Yeah, I was wrong. Let me rethink this.
---------- Post updated at 12:32 PM ---------- Previous update was at 12:28 PM ----------
Okay, so the clients are already sharing memory.
1) How are you mutexing this? Are you mutexing this?
2) Lots and lots of ways to handle server-client communication, but shoehorning that into the shared mem would just be building your own ad-hoc sockets. Might as well use real sockets.
Hey guys thanks for your interest. The server program initializes game character structures and stores them in shared memory. The client side process listens for user input and modifies the game character structures accordingly. On changes to the character structures the server does some graphical handling to indicate these changes to the user. What I need is a means for the client side program to connect to a server side program which is already running in order for the server side program to run a method that initializes a character structure in shared memory and spawns off a user process to listen for input from the terminal that the user 'connected' from.
---------- Post updated at 01:35 PM ---------- Previous update was at 01:34 PM ----------
btw..all users that could possibly connect to the game are gonna be running on the same machine but different terminals...just in case you find it relevant
What do you mean by 'terminal'? Do you mean that literally -- the server has to take over the client's terminal device? Or do you just mean the server has to listen for input from the client process?
How are you mutexing the shared memory? Are you mutexing the shared memory?
Lots and lots of ways to handle server-client communication, but shoehorning that into the shared mem would just be building your own ad-hoc sockets. Might as well use real sockets.
the clients terminal device must cause the 'server' process to register it within the server process and initialize a shared memory segment. I don't see the need for mutexing as the shared memory segment is being modified by only one process and read by only process also. Hence no corrupt data can occur. I was hoping to implement this without the use of sockets.
Race conditions can still happen when the server is interrupted while writing to the shared mem. Until the server finishes, clients would view incompletely-updated data. If your data structure is just a "video buffer" this probably won't cause crashing, though you could get the ASCII equivalent of video tearing.
Might UNIX domain sockets work for you? They're not network sockets per-se, local-only, and designed for your problem(among others; things like syslog, mysql, and X11 also use them for local communication.) They're like beefed-up FIFOs. The server creates a special file, probably under /tmp/ or /var/run/, which clients connect to. Unlike fifo's, more than one client can connect simultaneously. The server checks for connections with the accept() system call like a network socket would. Once that succeeds there's a communication channel between the client and the server. The server would fork off a process to deal with this connection and close its own copy afterwards.
There's no easy way beyond this, really. That's what this is there for. If you want to do without you'll just be building your own private version of the same thing.
Thanks for your help...very much appreciated...I'll try to learn some more about domain sockets as I'm not that familiar with the topic.
---------- Post updated at 04:38 AM ---------- Previous update was at 04:27 AM ----------
one last thing hehe....do u guys have any idea of how I can distribute the same screen among multiple terminals ? I am using ncurses and want to distribute the WINDOW structure to all the connected terminals.
ncurses didn't work that way last time you asked, and continues to not work that way now. Each process will have to be responsible for its own drawing and nobody else's.
It's a variation of a fairly common question actually: "how do I write to 9 files with one fd?" You really can't. Yours is complicated by three layers of other problems though!
do you think it's possible to have a process write the WINDOW to a file which multiple processes read from simultaneously ? I had tried to do this using shared memory by having the window kept in shared memory but each time I accessed the window from the child process I kept getting a segmentation fault. Any ideas ? Thanks for your help and patience btw..thank god for ppl like u!
curses won't treat a file like a terminal and won't be fooled. Besides, whose to say all your clients will be using the same terminal? You need to let your clients do their own drawing.
This is because, as stated twice previously, curses does not work that way. A WINDOW structure created in one process won't be valid in another. In fact any pointers and things containing pointers won't be valid when shared. Pointers point to memory local to its process, if they even point to any valid memory in a different process it will be a complete coincidence.
I think you're going to have to give up on sharing terminals with other processes and share data with them instead. Tell them what to draw but let them do their own drawing. (or just redraw everything every frame, and make it more efficient later.) You could keep an 80x25 character array in shared mem, and communicate to your clients what sections they need to redraw, or perhaps just when. I do think you'll need synchronization to accomplish this well.
If you have shared memory, why does the server need to handle the input?
The client process writes and reads shared memory. What else is needed?
fully agree with you.
Reinventing inter-client communication with shared memory is essentially building your own pipes and sockets from scratch. Besides, he said he didn't want to do any synchronization.
Wait, you don't actually agree with him, you're a spammer advertising something.