What's a good alternative to browser-webapp-webserver for remote apps?

[rudder]

I'm familiar with the typical web-based way of multiple users interacting with a remote application: web browser talks to webapp (usually running on a web server like apache) via http. What's a good alternative to that if I want to eliminate the browser and maybe even the webserver?

That is, I'd still like one central server app running on a remote server, with users running a local app to talk to it over TCP/IP, using some standardized protocol. Any recommendations?

(Edit: the background here is that that I'm curious about the options available for where you'd have a local desktop game talk to a remote game server (multiple clients, one server).)

[Corion]

You haven't told us what kind of server you want to write. XML/RPC, HTTP and 3270 host terminals are basically all the same thing and likely the idea of a request/response based, mostly stateless protocol is the only sane way to handle stuff at all.

You don't need to use HTTP if you want Apache. There are implementations of SMTP for Apache, and there are webservers that are not Apache. Perl has two single-process socket server frameworks, POE and Coro. If you want a custom protocol, you will need to write a custom server and a custom client, which both implement the custom protocol. See CFPlus and IRC for examples.

[Joost]

So basically you want to use some other client? *And* you want to use a standard protocol?

Well, there's X, which should work everywhere, but is probably a lot more network intensive, but you should probably explain what you need that isn't provided with plain HTTP/HTML or maybe even HTTP/XUL (See http://www.mozlla.org/projects/xul/). Note that basically anything except plain HTTP/HTML will require the users to install additional software.

update: since you say it's for games, you may want to consider flash. not as good as standalone directx/opengl but immediately portable, and it supports (again) HTTP communication.

I think if you're serious about making money with games you probably will have to choose between either a fairly costly commercial engine or writing your own framework at least if you want to do 3D (though there are a few open source engines if you look for them). In any case, unless you go for flash you'll probably have to provide your own client.

You may want to check out OpenGL and SDL for the rendering, and any kind of network module for the connectivity.

[Your Mother]

POE.

[rudder]

Thanks. POE looks like it could be interesting, but I must admit that I can't really make heads or tails what it actually is or in what circumstances I'd want to use it. It's docs seem to assume you already know those 2 things.

The nearest thing I could find to an introduction was this Perl.com article, though haven't worked through it yet.

[Your Mother]

This is the best place to start, POE Cookbook. Lots of small working samples of managers, clients, servers, and combinations of them. (update: up-cased Poe.)

[TGI]

There was a recent a post about a game called The Glass Bead Network on the POE mailing list that you might find interesting.

[perrin]

I'd still like one central server app running on a remote server, with users running a local app to talk to it over TCP/IP, using some standardized protocol

If you want a useful answer to this, you'll need to tell us why you don't want to use HTTP for the protocol and why you don't the server to a web server running mod_perl or FastCGI. You can make a custom client (e.g. some GUI software) that speaks HTTP if you object to using a generic web browser.

[rudder]

I've been investigating how multiplayer online games work. What I've found is that many simple games are flash based. So, to play them, you've got a flash app running in your browser, communicating with a web server presumably via http sending something like xml back and forth. This seems inefficient.

What I'm curious about is more sophisticated games -- desktop games, with multiple players, communicating with a central game server.

Perhaps the standard way to do that is to use http with mod_perl (or FastCGI)... I don't know. How is this sort of thing usually handled these days?

[dragonchild]

In general, they follow the old client-server model because of the need to have a custom protocol for updating the graphical elements. This generally entails some sort of half-model-plus-protocol that replicates most of the model information on the client. This allows the server to send very little information to the client for a large effect on the client. Having written one of these in AJAX, this takes either
• A large amount of duplication of effort across two languages
• Two completely different applications that both speak the same protocol
Neither of these is simple to maintain. This is why those MMORPGs suck, have few features, or have a monthly cost.

[perrin]

Network protocols for actions games are going to be heavily affected by the demands of the game environment in a way that makes them poor choices for other applications. For example, action games are very concerned about latency and about minimizing network traffic in general. That will lead to very compact binary protocols that are difficult to write and torture to debug.

For other network applications -- a shared spreadsheet, a turn-based strategy game, etc. -- those issues are less of a concern, so an easy and widely-used approach like XML over HTTP makes a lot of sense.

Although I've never written one, I'd guess that modern MMORPGs are commonly written as multi-threaded daemons in a low-level language like C++ with some kind of higher level "scripting" language built in for implementing most of the game functionality. This is very similar to a mod_perl or FastCGI setup where you have a daemon (the web server) handling all of the tricky network stuff and you build the high-level functionality in perl.

If you specifically want to know about certain games, I bet you can find details about their implementation and protocols with a little Googling. The developers usually give interviews with at least general information.

[ruzam]

The reason they're flash based and run in a browser is because that way you don't have to develop a client side application. Anyone, from anywhere, with any kind of flash compatible browser can play. It may be inefficient, but it's universal.

For the more sophisticated games, you need to create a client application. Users have to trust you enough to download and run your client software. Given what's on the net these days, that can be a hard sell (who's to say your client isn't another spyware app?). Then you have to support the client, running on who knows what hardware, with who knows what version of operating system, etc, etc. Some users will be excluded from your game by way of what computer they use (Mac, Windows, Linux, other). All in all alot of extra work that takes you away from your real goal of making the best darn game server you can.

Communicating over the net doesn't have to be http. You can use any port and what ever communication scheme you want over a bog standard TCP connection. The client doesn't have to be a browser, the server doesn't have to be a web server, and neither of them have to follow a valid HTTP protocal. If you're not running the client from a browser, then there's no reason to use HTTP, but it does have one particular advantage in that it usually won't be blocked by firewalls (the port that is).

[DBAugie]

Everything that's old is new again.

It sounds like you want the client-server model of system architecture. Back in the day, this was Very Hot Stuff in the database world. The database functioned as the central server application and many developers wrote client applications that were distributed to the end-users. As long as the whole system did not scale beyond the capabilities of the system managers and developers to maintain, it worked relatively well.

The problems started when the individual applications begin tromping on each other; taking exclusive locks on resources and not releasing them; resetting variables without checking if they are already in use; etc. The issues compounded when it was time for a new release of the client software and you distributed the new client software to many users with a bewildering array of operating systems at various patch levels.

Usually, I saw clients and servers communicating via tcp with remote procedure calls (rpc). If you have any Old Guys around, they probably have linear yards of bookshelf filled with books on the subject.

Good luck

Augie

[derby]

I'd have to agree with perrin on this one. HTTP is *the* standardized protocol The only downside of HTTP is the mindset that it means a browser and HTML - it doesn't.

[zentara]

I would go with Net::EasyTCP. Why? It has built in encryption, port passwords, and the ability to send hashes thru the socket without manually serializing them. Here are some examples I have(read the module's README and docs. I havn't messed with it in a few years, and there have been some updates about encryption handling)

Sockets-File-Upload with Net::EasyTCP

ztk-enchat encrypted server client

and here is the basics of a server and client, note the slight slowdown due to encryption

#server

#!/usr/bin/perl
use Net::EasyTCP;
#my @nocrypt = qw(Crypt::RSA); #too slow, but more secure
#my @nocompress = qw(Compress::LZF); #just testing this feature

$server = new Net::EasyTCP(
    host  =>  "localhost", 
    mode  =>  "server",
    port  =>   2345,
    password => "ztest",
    donotcheckversion => 1,
#    donotencryptwith => \@nocrypt,
#    donotencrypt => 1,
#    donotcompresswith => \@nocompress,
#    donotcompress => 1,
    welcome => "Hi! Wecome to the test server!\n",
    )
       || die "ERROR CREATING SERVER: $@\n";

$server->setcallback(
     data            =>      \&gotdata,
     connect         =>      \&connected,
     disconnect      =>      \&disconnected,
    )
     || die "ERROR SETTING CALLBACKS: $@\n";

$server->start() || die "ERROR STARTING SERVER: $@\n";
####################################################
sub gotdata() {
my $client = shift;
my $serial = $client->serial();
my $data = $client->data();
print "Client $serial sent me some data, sending it right back to them
+ again\n";
$client->send($data) || die "ERROR SENDING TO CLIENT: $@\n";
if ($data eq "QUIT") {
$client->close() || die "ERROR CLOSING CLIENT: $@\n";
}
elsif ($data eq "DIE") {
$server->stop() || die "ERROR STOPPING SERVER: $@\n";
}
}
#####################################################
sub connected() {
my $client = shift;
my $serial = $client->serial();
print "Client $serial just connected\n";
}
###################################################
sub disconnected() {
my $client = shift;
my $serial = $client->serial();
print "Client $serial just disconnected\n";
}

#client

#!/usr/bin/perl
use Net::EasyTCP;

$client = new Net::EasyTCP(
mode            =>      "client",
host            =>      'localhost',
port            =>      2345,
password        =>      ztest
)
|| die "ERROR CREATING CLIENT: $@\n";

my $encrypt = $client->encryption();
my $compress = $client->compression();
print "encryption method ->$encrypt\ncompression method ->$compress\n"
+;

my $encryption  = $client->encryption()  || "NO";
my $compression = $client->compression() || "NO";

print "Using $encryption encryption and $compression compression\n\n";

#Send and receive a simple string
$client->send("HELLO THERE") || die "ERROR SENDING: $@\n";
$reply = $client->receive() || die "ERROR RECEIVING: $@\n";
print "$reply\n";

#Send and receive complex objects/strings/arrays/hashes by reference
#%hash = ("to be or" => "not to be" , "just another" => "perl hacker")
+;
#$client->send(\%hash) || die "ERROR SENDING: $@\n";
#$reply = $client->receive() || die "ERROR RECEIVING: $@\n";
#foreach (keys %{$reply}) {
#print "Received key: $_ = $reply->{$_}\n";
#}

#Send and receive large binary data
#for (1..4096) {
#for (0..255) {
#$largedata .= chr($_);
#}
#}
#$client->send($largedata) || die "ERROR SENDING: $@\n";
#$reply = $client->receive() || die "ERROR RECEIVING: $@\n";

#$client->close();
$client->send('Hello from Joe') || die "ERROR SENDING: $@\n";
$reply = $client->receive() || die "ERROR RECEIVING: $@\n";
print "$reply\n";

while(1){
$input = <STDIN>;
$client->send($input) || die "ERROR SENDING: $@\n";
$reply = $client->receive() || die "ERROR RECEIVING: $@\n";
print "$reply\n";
}

[Gavin]

Considerable development is under way using P2P networks to develop multi user game applications notably using JXTA technology.