Design patterns for servers with long life sockets?

magnus.wolffelt@gmail.com wrote:

> Thanks for the replies. I do already have an automated test that does
> the whole log in procedure.

Small or large granularity tests?

> I have actually had the server working quite well, even to the point
> where after loggin in the client would receive a world definition (a
> 2d grid basically, think pacman).

Patrick is about to give you one of his standard lectures about how lots of
small-granularity tests are a design technique, allowing you to refactor a bad
design - in between adding features and deploying versions - and fix the design
as you learn more about its requirements. Lots of tests make starting with a bad
design safe.

> Well, how does one reliably handle logging in and staying logged in
> with UDP? Isn't that a sort of state?

If UDP may indeed rest in peace, then we are talking about a layer over TCP that
is...

- stateless
- secure
- broadcastable
- guaranteed order-of-delivery

Put the first two together, then any datagram that arrives must contain a unique
code that can only have been generated by a combination of the secret keys that
your client and server exchanged at login time. So login and security provide
state over stateless wire protocols.

Then, each datagram should update an object model. That is "event driven
programming", the arch-enemy of stateful connection programming.

--
Phlip

magnus.wolffelt@gmail.com wrote:

> out of curiosity and personal interest I'm writing a simple
> multiplayer game server that uses TCP.

> Players will be able to log in with username and password, and with
> each account one and only one "character" is associated. The game
> itself will be very simple - that's not what I want to discuss.

> I'm trying really hard to find an elegant structure for the whole
> "connect", "log in", "start playing" procedure. Primarily it gets very
> messy with the socket - character association and the messages that
> need to be considered and potentially discarded, depending on "client
> state". Multiple threads make it even worse.

> Are there any useful design patterns out there for creating elegant,
> robust and maintainable servers that have persisting sockets? What I
> mean by persisting sockets is that the server does not function as a
> pure "read, interpret, reply, close" service, but rather where sockets
> are kept open for a long time and a continuous stream of messages are
> sent back and forth. Usually this type of server also has several
> states in which clients will be considered - depending on whether they
> are logged in or not and so forth.

1. What you are looking for (in OSI terms) is comms *session management* .

A session is a communications channel that is ignorant of the *transport*
resource activity needed to maintain that session.

With TCP being an instance of a transport resource, what this means is
any of the following may occur over the lifetime of the session :

- transport connections may be established/released any number of times

- any number of transport connections may be concurrently established to
support the session


2. Now, given session (data rate/throughput/latency etc) and transport
(IP port availability etc) requirements, this will determine how the
transport resources are utilised.

3. The simplest framework is to have a game session component.
The simplest implementation is to associate one TCP port with the
session, and have the transport connection open for the lifetime of
the session.


So ...

- Start with 3.

- Have a cursory look for something suitable providing 1.

- Gather metrics for 2. Change your session impl accordingly.

- If you feel you are doing a lot of work implementing the session,
do a more serious search on #1.


Regards,
Steven Perryman

"magnus.wolffelt@gmail.com" <magnus.wolffelt@gmail.com> wrote:

> out of curiosity and personal interest I'm writing a simple
> multiplayer game server that uses TCP.
>
> Players will be able to log in with username and password, and with
> each account one and only one "character" is associated. The game
> itself will be very simple - that's not what I want to discuss.
>
> I'm trying really hard to find an elegant structure for the whole
> "connect", "log in", "start playing" procedure. Primarily it gets very
> messy with the socket - character association and the messages that
> need to be considered and potentially discarded, depending on "client
> state". Multiple threads make it even worse.
[snip]
> Any good resources/books for this type of servers?

Try:
http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf

> Try:
> http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf

Ooh, yeah!

Now, Patrick, you need to come down on Dr Schmidt like a tonne of onions, too,
regarding his students' _unit_ test situation!

Phlip <phlip2005@gmail.com> writes:

>> Try:
>> http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf
>
> Ooh, yeah!
>
> Now, Patrick, you need to come down on Dr Schmidt like a tonne of
> onions, too, regarding his students' _unit_ test situation!

Sheesh, I channel you once and now I'm forever haunted. Time to
call my friend who was raised in Santeria....

It was nice to see the Booch clouds again, though.

Regards,

Patric

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

> Sheesh, I channel you once and now I'm forever haunted. Time to
> call my friend who was raised in Santeria....
>
> It was nice to see the Booch clouds again, though.

Hmmmm. Santeria... clouds... Hmmmm...

--
Homer Simpson

>
> Try:http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf


Very cool from first look. Will definitely read the whole paper. This
is what I was looking for.

magnus.wolffelt@gmail.com wrote:

>> Try:http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf
>
> Very cool from first look. Will definitely read the whole paper. This
> is what I was looking for.

Warning: It will lead you to ACE, which will appear to satisfy your
requirements... at the cost of your mortal soul. Other than that - no strings
attached!

--
Phlip

Phlip <phlip2005@gmail.com> wrote:
> magnus.wolffelt@gmail.com wrote:
>
> >> Try:http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf
> >
> > Very cool from first look. Will definitely read the whole paper. This
> > is what I was looking for.
>
> Warning: It will lead you to ACE, which will appear to satisfy your
> requirements... at the cost of your mortal soul. Other than that - no strings
> attached!

You say that like its a bad thing...

> Warning: It will lead you to ACE, which will appear to satisfy your
> requirements... at the cost of your mortal soul. Other than that - no strings
> attached!
>
> --
> Phlip



No worries - I intend to keep this in Java.. perhaps using some
existing tools like:
http://java.sun.com/j2se/1.5.0/docs/...utureTask.html
and
http://java.sun.com/j2se/1.5.0/docs/...kingQueue.html
and
http://java.sun.com/j2se/1.5.0/docs/.../Executor.html