Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm developing a simple 2d online game and now I'm designing my server. The server will be run on linux vps and I need a way to communicate with it (for example to close it, and as it will be run on vps, simply closing terminal won't work). So I think there are 2 options:

1) Write 2 apllications - server which doesn't say anything and doesn't accept console input and the second application is console which sends commands to server (like exit, get online players etc).

2) Have 2 threads on the server appplication - one is the real server, the second thread will be used for cin and cout. However I'm not sure if this will work on vps...

Or maybe there is better aproach? What is the usual way of doing this?

share|improve this question

2 Answers 2

up vote 0 down vote accepted

You can definitely use stdin/ stdout on a Linux or Windows-based server process. It is possible to multiplex it (with sockets, for instance), or handle it in a separate thread from the rest of your server (only useful if you have sufficient locking, or maybe do something simple like queue the commands for your server).

In Linux it is common practice to run such a server under a persistent-terminal program such as "screen" or "tmux", then you can log in later (securely, e.g. via ssh) and look at the output, and supply input.

Likewise, if it's a Windows server, you can run it in a remote desktop session and then reconnect later.

Do the simplest thing which could possibly work; you'll have bigger problems.

share|improve this answer
    
Thank you. So if I understand correctly, I just write normal console app with second thread for console i/o and on vps I just launch it using the "screen" command, yes? And that way when I login to my vps via ssh, how can I acces my server app running in that screen? I have no idea I'm new to vps. –  user1873947 Jan 14 '13 at 15:24
    
It's not necessary to use a second thread to process console input, but that's one possible implementation. In principle you could write console output from anywhere in your code (but doing so from multiple threads might require some locking to avoid garbled output). "screen" will keep a virtual terminal (pty) open while you're not connected, and you can reconnect to an existing session using "screen -r". See its man page for more info. –  MarkR Jan 14 '13 at 17:20
    
Thanks. Could you tell me what's the other way of processing console input without threads? Cin is blocking and the server is real-time so I have no idea, but it would be interesting and easier. –  user1873947 Jan 14 '13 at 17:35
    
Just multiplex the console (stdin) with your other inputs (e.g. sockets). The multiplexing system you're using for the other sockets will have a way of doing it. For example, OpenTTD dedicated server does this. –  MarkR Jan 14 '13 at 20:28
    
I'm not a native speaker and I don't understand whut multiplex means in this. Do you mean something like selector for sockets? Could you explain it in more easy way? –  user1873947 Jan 14 '13 at 20:59

If you're running your server from a remote host, you'll absolutely need to use the first option. Otherwise, I would go with the second option for simplicity's sake.

Keep in mind that if you use the first option, it's possible that hackers will be able to shut down or modify your server. At the same time, though, you also get the added benefit of allowing administrators other than you to perform these operations.

share|improve this answer
    
Okay, so that's what I thought that 2nd option won't work on vps. And no, it won't be a security breach - I'll use SSL login and connection. –  user1873947 Jan 13 '13 at 17:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.