ASM Community

patform SDK, WINSOCK2.h

/*
* WinSock 2 extension -- manifest constants for WSASocket()
*/
#define WSA_FLAG_OVERLAPPED          0x01

as for the rest - I don't know anything :P

Thanks, I'll take a peek :)

You are welcome.
Regards.

Kecol.-

James - I'm developing an iocp framework for the ObjAsm32 dev team.
Do you think you can stomach the source? It looks pretty weird at first :)
I'm also developing a banked socket framework using the Event objects model (the class defines a bank of 64 sockets plus selfcontained workerthread and abstract-static event handlers) as well as the various utility classes like Socket which are common to both socket models.
The banked socket framework currently does not use overlapped io because I see it as redundant under that model - can you change my mind?
If you still want to see the source and/or contribute, I welcome you aboard - PM me :)
If not, I understand completely, perhaps in time you will change your view regarding oopasm.

Sure.. I'll explain it in 1000 words or less :)

Let's suppose we are using eventobject-driven socket model.
We know we can only monitor 64 sockets per worker thread (hanging on WSAGetMultipleEvents).
A bank of sockets is an array which stores up to 64 sockets.
In my case, I created Socket and SocketBank classes.
Each instance of SocketBank (an instance is an Object) manages two arrays of 64 elements.
One array contains pointers to instances of Socket object (contains hSocket and other stuff), and the other array contains hEvent handles which have been associated with the Socket whose pointer is stored at the same index,different array.
SocketBank ensures that the active elements (especially in the event handles array) are always stored in the lowest possible indices in the arrays, so that we basically have at least got an array of event handles which are A)associated with sockets and B)all valid, and together at the bottom of the array.
Now we can call WSAGetMultipleObjects on the event handles array, telling it to monitor N handles.
SocketBank instances each have their own WorkerThread, which can be paused and killed via event objects.

Just because I can, I defined the actual socketevent handler methods (procs) as "abstract methods" in SocketBank class... then derived two new classes from SocketBank called SocketClients and SocketServers.
SocketServers stores up to 64 listening server sockets.
Each of these owns an instance of SocketClients in which it stores Accepted clients.
So we have a (SocketServers) SocketBank worth of (Listening) Sockets which each own a (SocketClients) SocketBank worth of Client sockets.
We can handle 64 servers, and 64*64 clients, with a single instance of SocketServers.
Of course, these are artificial limitations imposed only by the implementation (you can make more instances, use an array or linkedlist of socketbanks to manage them, etc).

I should point out that whenever socket events are not occuring, the WorkerThread(s) are asleep and consume no cpu time and create no context switches.

Have a nice day :)

Forking per clientsock is a horribly inefficient approach, and begging to be resource-DoS'd.

One thread per socketbank.. the thread is actually written as "part of socketbank", so when we create an instance of socketbank, we automagically create an instance of the worker which is solely responsible for the 0-64 sockets in that bank. All these Workers can be individually paused and resumed and terminated from outside the thread.

Each socket in the bank has its own event object and is uniquely associated with any combination of the FD_XXX events.

You can decide when you create/add sockets to a bank, or at any later time, what events will trigger each eventobject.

Here's today's posting from the OA developers private board:

I didn't even get it to echo - but I have faith :)
I did get it to hang on accept, so thats something :P

Thanks for the comments.

Bug reports are welcome. Im looking into all of them.

I have updated the site with a plan and hopefully this will appeal.

FAStServer is a work in progress, so expect some changes and some bugs. However,
I do expect to have a plugin example which should stay constant regardless of the
changes in the server. So you should be able to confidently build a plugin and not
worry about the driving server. This will improve over time without requiring the
plugin to change. Which is what I would want.

If you have issues with the license then please let me know what they are.

Ultrano - The reason you get the headers twice is because when the acceptex is done, it also gets a buffer of data. Which is the
http get request. The second request isnt a new request but the first read. This is just done as an example as FASt Server is a
work in progress.

Thankyou for your support and comments.

rgs James.

Homer,
No kick from me.
:)

re Piping : my first impression is not good.
You are just adding a "notification mechanism" to something that already supports direct callbacks !!

re pseudocode for WorkerThread :
The thread should always use one of the various Wait functions to wait for network events.
In the case of IOCP, the GetQueuedCompletionStatus function is provided.
This function effectively puts the thread to sleep pending completion of a queued IO event, and I quote :


That is to say, if theres nothing queued, it will immediately return with error.
If theres events queued, but not completed, it will BLOCK until something completes, or until the specified timeout elapses (which can be infinite).
If theres at least one completed event, it will return some data regarding that event.

Using the underlying operating system's mechanisms for notification of completed events (and to perform a blocking poll) simply has to be the most efficient option.