Another update was made (same URL as always).
The 60 second time limit is gone.
The demo of a driving exe now has a window with only system controls so far.
Closing it will kill the server.
The window really has nothing to do with the server right now, but it does provide an excuse for a loop and a convoluted means to destroy the server..
I use the OA32 macro "ObjectsDone" in the OnDetach handlers of my DLLs.
Unloading a DLL causes shutdown and cleanup of any OOP stuff within that DLL instance :)

Posted on 2005-06-29 09:52:33 by Homer
Do you do a WSAStartup and WSACleanup in the process attach / detach of the DLL ?
It is recommended that you do.

Can you report the URL for the lazy people among us ?

Rgs, James.
Posted on 2005-06-29 15:56:42 by James_Ladd
No, I perform those in each DLL's object constructor.
I should move them, but I didn't foresee an owner exe creating >1 instance of Server which use the same protocol plugin..
Latest public update, as always, is, which is liable to be updated without notice..

IMHO I have completed the Server, and am working on several protocol plugins.
My plugin interface looks different to yours.
I derive each protocol plugin from a class called Plugin, whose interface looks like so:

  StaticMethod    OnReadCompleted,Pointer,dword   ;-> XOVL, dwBytes
  StaticAbstract  HaveCompleteProtocolPacket,Pointer  ;-> XOVL
  StaticAbstract  ProcessCompletePacket,Pointer   ;-> XOVL

Plugin provides the OnReadCompleted function, but not the other two, they are only defined as provide them in each protocol plugin.

HaveCompleteProtocolPacket checks for a complete protocol message in a receivebuffer.
TRUE causes ProcessCompletePacket to be called.
FALSE causes the receivebuffer to be preserved for appending.
ERROR_BADPROTOCOL causes the Client to be kicked.

ProcessCompletePacket processes a protocol message, removes it from a receivebuffer, then jumps back to check for any more complete messages.

Any volunteers to help write protocol plugins?

Posted on 2005-07-01 04:28:05 by Homer

Great progress.

Id be inclined to rename HaveCompleteProtocolPacket to "HaveCompletePacket" or "HaveCompletePacketForProtocolPart"
since you dont actual know the protocol being implemented and therefore dont know if the
packet represents a complete part of the protocol.

This would also keep the fact that packets can be split up when sent in the mind of the protocol
implementor. ie: a single complete read does not equal all the packets needed for a message.

Rgs, james
Posted on 2005-07-01 18:21:06 by James_Ladd
I originally named that proc "HaveCompleteProtocolMessage", as some messages of some protocols can easily exceed one carrier protocol packet, which is what I believe you just said also...

I have retained support for mutiple concurrent IOJobs (N xovls) per Client, but theres still no mechanism for "tagging" a series of IOJobs , then again I'm still using a single worker thread instance (afaik).. I haven't encountered out-of-order IOJob completions yet :P
Posted on 2005-07-01 21:45:57 by Homer
So hows it all going ?
I posted a new version of FAStServer which uses OVERLAPPED structures properly to improve
the parallellism of the server. The plugin stuff is happening soon.
Rgs, James.
Posted on 2005-07-09 17:49:12 by James_Ladd
I got to the plugins stage also.
I started writing a couple of protocol plugins, and got bored.
I started concentrating on a gameserver, then realized that I should be using UDP.
Then I wrote a very humble UDP based server and client.
Then I wrote and implemented a basic game protocol.
Then I reworked my 2D MazeGenerator for 3D mazes.
Now I'm working on a 3D GameClient for opengl.
I'm not bored anymore :)

Yesterday, for example, I translated a multi-format TextureLoader class from C++ to OA32/MASM.
The C was ghastly - VERY unoptimized, VERY trashy, TYPICAL gamedev stuff.

It's nice when your interests find common ground, isn't it?
Posted on 2005-07-13 18:22:49 by Homer
Its nice the shotgun-approach to project selection works for you ;)
I try to focus on work and home code only. More than that would do my head in.
I havent had a lot fo time to code at home right now, but hopefully I will soon.

Id be keen to discuss the UDP server game thingo.

Rgs, James.
Posted on 2005-07-14 02:40:45 by James_Ladd
The UDP Server Thingo is quaint, it's currently a blocking thread pending recv, but could easily be implemented under iocp...
More interesting than the UDP Server Thingo is another potential use for iocp - processing game events as opposed to performing overlapped io (socket or otherwise).
That is to say, an iocp and its thread pool can be used as the core of a game engine, both client and server sides can benefit from it.
It's as simple as posting jobs and completions ourselves... we can even abuse the pOverlapped and pCompletionKey parameters for any purpose we choose :)

As for my "shotgun approach", that's not an accurate appraisal of my madness.
I tend to "round-robin" my projects, ie, I rotate them, with "winners" getting more of a look-in than the rest. Also, many of my projects are modules of larger projects, and finding common ground is not difficult.
My selection of projects is neither arbitrary nor ad-hoc, but NONE of them is a priority, because NONE of them pay my bills. They are all love first, money later projects.

Posted on 2005-07-14 03:26:14 by Homer
I hope you did not get offended by my "shot-gun" comment. I think you have a lot to offer
and id like to see the finished results of one of your projects.  Im just greedy and want you
to spend your time on one :)

I would not suggest using IOCP for game event handling as it has a major drawback in that
you can not cancel an event in the queue, you have to process it. Nor can you peek
an event in the queue.

There is a faster way of handing off events to be processed by threads which I am "guessing" is not
used by the IOCP layer.

My idea/goal would be a simple UDP server that communicated a time to all those clients connected,
they in turn would return the time and the server would record the latency of the return.
This is to form a base line server.

Anyways, keep well.

regs James.
Posted on 2005-07-15 18:22:29 by James_Ladd
Actually James, you CAN cancel pending events, I read about it recently, I just can't remember which api functions were involved.. as for Peeking the queue, yeah thats a no go.

Bah @ being offended, my skin is thicker than that :)

It's important to synchronise client time to server time.. server should send time to clients, and clients should ack this, but we shouldn't rely on the initial round trip time as an accurate appraisal of perclient ping, because due to unstable routing, this can change dramatically, both over time, and sporadically between packets (we should not presume that a given client's packets will have the same latency as the route is not guaranteed, packets may be routed differently based on the loading at individual routers, if they are not simply dropped, which is the usual case for cheapass telco routers).
Therefore, the perclient latency should be measured EVERY time a packet is received by the server. Then we can apply a heuristic to each client such that we can detect trends in the latency - we can forgive spikes, but if the average latency gets out of hand, we can do something about it.

Posted on 2005-07-21 02:03:11 by Homer
Posted on 2005-07-22 03:32:19 by James_Ladd
James - I am led to believe that pending socket io events can be cancelled with the (undocumented) NtCancelIOFile (ZwCancelIOFile) api function.
I've not tried it, and have no idea how it affects the completion queue, but I'm guessing it generates "failed io was dequeued" events.

I've done a fair bit of work on a protocol plugin for my Server core, it's an implementation of Yahoo's YCHT protocol.
Also, I've created a very basic GUI for the "driving exe" demo application which "peeks at" various runtime variables within the Server core, such as how many Clients are currently connected, and the state of various Object Pools.

I'll be reposting the entire thing in the near future.

Have a nice day :)
Posted on 2005-11-12 07:29:59 by Homer