Question

I am developing a game in Flex.

There are both AIR and Web versions of this game.
AIR app would connect to a server using a UDP socket on a port.
The purpose of the Web version is to allow users to play when they are at work, or on a computer behind some firewall/proxy that blocks some ports. So the web would connect to a server using http connection on port 80.

The server code answering the http connections would be a java servlet that uses BlazeDS.
But if any of you find it more easier to explain for a C# server code(webservices or whatever), it would be ok .
The server code answering the UDP requests would be a simple class listening for socket connections.

My problem is I don’t know how to put UDP and http code together. If there are 5 AIR clients, and 5 Web clients, they all need to meet in the server in some common collection variable, so that I can update all clients with latest info.
Who is going to instantiate the class that listens for sockets? And when?

So to summarize:
1. Do I need a dedicated server to achieve what I want?
2. Who will instantiate the udp handling class and when?
3. Is it even possible to keep the udp handling class and the servlet for http connections together? If there would not be http, I wouldn’t even need tomcat. But http and udp code need to stay together, so that I can update the players collection. Is it possible to instantiate the UDP handling class and tell it to listen for socket when the servlet is deployed on the server…or something like that?

Any advices are more then welcome.
Thanks in advance,
Miha

Answer 1

http and udp code need to stay together

No they don’t. They are transport mechanisms for your game data, so they should be transparent. Your UDP and HTTP servers should connect to your game backend, in what way is up to you. It can be in-memory, by using HTTP and UDP (socket) modules directly from your backend code, or it could be using some sort of service (so you can let other channels talk to the same backend).

This game backend does not connect directly to the user but only talks to the UDP and HTTP modules.

Then from this backend you process messages you receive from both HTTP and UDP, and sends the response over the same channel.

Example:

1. AIR-client 1 sends a valid login message to UDP server.
2. UDP server forwards the login message to the game backend.
3. Game backend returns succesful result message to UDP server
4. UDP server forwards the result message to AIR-client 1.

Example 2:

1. Now HTTP-client 1, which happens to be already logged in, requests all users currently logged in. It does so over HTTP, to the HTTP server.
2. HTTP server forwards this request to the game backend.
3. Game backend returns information to HTTP server
4. HTTP server returns response to client.