Hi all,

An intro to me, my name is Trevor Herselman in real life ;)
I currently work in South Africa where I'm lead developer on database validation software for our IBML scanners. The scanner is the fastest in the world and comes from Alabamma in the USA. It scans @ 200 A4 pages per minute in full color (there is a 400 page per minute model), and does hardware OCR and barcode recognition. What I design mainly is the software to make sure the scanner has writen the correct values to the SQL database when it does the hardware OCR and barcode recognition. The scanner is used in most airlines worldwide to scan airline tickets doing ticket barcode recognition. Other uses include scanning of cheques for banks or anywhere a paperless office is a fantasy! The scanner saves files in mainly TIFF and JPEG format. I use C/C++ mainly at work but have the rare opportunity to use assembler whenever I want to (or whenever I can finish the project in time using it!) I've been programming for half my life already, 13 years, I'm 26 years old for those that can't do math (like me) and I've been a "fly on the wall" of this board for over 2 years. During this time I've frequently read the new updates, on average about 3 times per week but I haven't contributed much. It's taken me about a week to put these 2 projects in a format that is presentable to the community. By adding LOTS of comments and reformatting my code for readability. This leads me to today's post, cause today I hope to give a small gem back to the community that taught me so much!

Basic Description:

The zip file consists of 2 small RadASM projects (.rap thanx to Kitelo!) with multiple asm and inc files. Both have been written in MASM syntax with lots of high level syntax (.if .while & invoke etc) with loads of macro's (mostly made by me). The main reason I use HL syntax and macros is for readability. Macro's are used extensively for error reporting and to reduce code clutter. Maybe you find it more readable NOT to use HL syntax, good for you, you machine!
The main project is a WinSock enabled DLL, that controls all WinSock related events and activity including listening, connecting, sending and receiving. Using a semi-dynamic array to store the sockets, socket state, IP address and port. It currently uses WSAAsyncSelect for WinSock event notification and callbacks to provide the client with socket event notification.
The other project is the one I use to test and debug my DLL! It demonstrates most of the DLL's features and is basically just a form with several edit boxes and buttons. Sorry in advance for the very basic look and feel of this test app!

Design Principles:

Stability, functionality (being feature rich), ease of use and readability are high on the agenda, in that general order! As stability and functionality increase, I wish to move speed as a requirement higher on the agenda, particularly by implementing a more advanced overall design with IO Completion Ports. I also wish to implement a more graceful shutdown procedure, optional inline data compression and sofisticated send and receive buffers. I'd also like to provide a way to change the WinSock internal send and receive buffer sizes and other TCP/IP options like disabling the Nagle algorithm.

About the semi-dynamic array:

When designing a WinSock enabled app for example, you'll have to know what sockets are connected, what their socket number is and what state they're in etc. This DLL takes care of that using a semi-dynamic array I call Sox (short for sockets). You will notice that most functions require or return a Sox value, this is essentially just the array index number. I call it a semi-dynamic array because when a socket is removed, that slot will be used in the future but the array will not compact/reshuffle the sockets, it will only reduce the array count (shrink) when there are empty slots at the end of the array. The memory for all sockets (max sockets estimated at 8000, about 125K of RAM, or 16 bytes per socket) gets pre-allocated on DLL startup. Microsoft claims that Windows supports up to 25000 sockets, but I've only ever managed to add 7000 something sockets. The main reason it fails to reach this count is that it seems to reach a handle limit! Maybe someone can point out the design principles involved in reaching this 25000 limit! I've tested Win98, WinNT, Win2000 & WinXP with various WinSock projects (including VB's WinSock OCX and the C++ MFC WinSock objects) and never reached 25000 connections!

About WSAEventSelect and IOCP (IO Completion Ports) design:

Well, I researched these 2 long ago, so I can't remember all the Pros & Cons. But basically, WSAEventSelect is generally faster than WSAAsyncSelect, BUT, most people forget to mention that a call to WSAEventSelect can only monitor 64 sockets at any one time. So this might be best for multiplayer games but poses a major design obstacle for very active servers. There are several workarounds, you could add more threads and call WSAEventSelect on each new thread to monitor 64 sockets per thread, or you could loop through all your sockets, 64 at a time, but this is even more CPU intensive! Imagine you have 8000 sockets, monitoring them with 125 threads or looping through them. Maybe I'm overlooking something here or just don't understand WSAEventSelect. Oh, the other way was to create a custom event and link 64 sockets to that event, then monitor up to 64 of these custom events. That still only accounts for half the sockets and the other problem with this method is when an event happens on one socket, you'll have to re-check the whole group of sockets to find the one socket that fired the event. IO Completion Ports are only slightly more complicated to implement. Generally it only really helps to reduce CPU usage on large or active send and receive servers, but one of the other 2 methods still needs to be used. However, I mainly chose WSAAsyncSelect (with it's own headaches) for it's design and implementation simplicity!

About the callbacks:

I've read numerous articles on the pro's and con's of Callbacks vs. other event notification techniques. Basically, callbacks are fairly easy to implement but very fast because you simply call another function as if it were part of your app, obviously the function is written by the client! I liked the speed advantages of callbacks. Other techniques include using custom (sometimes registered) events (similar to WSAEventSelect), standard 'equate' type messages (similar to WSAAsyncSelect) usually sent to a wndproc, the standard COM event is often used especially in OCX controls or (my personal favourite) customized IO completion port messages. Problems with callbacks include: The client app will 'freeze' your DLL thread while processing the message and if the callback has error's, you could potentially crash the thread or DLL. Both these problems are sometimes resolved by creating a new thread to call the callback, but the problem with doing this is some client apps are not thread safe, so executing code on a new thread might cause instability for the client!
What I really like about using IO completion ports as an event notification system is that the client app will have to be thread safe, also the number of threads ready to receive and process your messages is controlled by the client! So if they have a multiprocessor machine, they can assign more threads to the IOCP making everything faster. I also like this because posting events to the client doesn't 'freeze' your app like callbacks! Well, callbacks will have to suffice for now!
NB: Using IOCP as a 'customised' event notification system is different in the above context to using it with WinSock's WSARecv and WSASend methods.

Some history:

I started on WinSock programming about 3 years ago by creating a small VB 6 chat app. I then had to create a small server app but I only had VB WinSock OCX experience and many people told me the VB WinSock control had memory leaks. So I decided to create my own WinSock OCX using the API in VB. This wasn't that successful because VB 6 isn't really thread safe, so I moved onto creating a C++ WinSock OCX using MFC and posted it on PlanetSourceCode. I got 12 excellent votes for my submission and won the coding contest. My DLL is partially based on that submissions concepts. I posted it there because there were not many examples of OCX programming in C/C++. I struggled myself to learn OCX programming in C/C++! To view my C++ OCX go here:
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=6364&lngWId=3

Reasons for this submission:

I initially designed the DLL to provide an overall, complete example of WinSock programming in assembler. There are many tutorials and articles out there with excellent advice and methods, but sometimes it's better to learn from (AKA steal code from) and enhance the methodology of a finished product, to see everything as a whole, functional entity.
I'd also like people to contribute feedback on enhancements, suggestions or bugs etc. My goal is to eventually create a high quality, feature rich, stable and fast WinSock DLL for application developers from the assembler community.
I hope and believe the main DLL is not the only thing people could learn from. I use multi-threading and therefore thread syncronization with a critical section (not that fancy I know!). I make extensive use of some very handy macro's, helping me to really really produce an assembler app in a shorter period of time. The macro's really help to reduce commonly used function calls. For example, I have a macro called mGetLastError (usually my macro's have an m prefix), this macro is used when an API fails, most of them return an error code which we get by calling the GetLastError() API. This macro automates this process, it gets the error code, converts it to a string, then get's the windows string associated with the error code from the internal windows resource files and concatenates them. With the macro you can supply a custom error message as well which also gets added to the whole string. All this is reduced to 1 line of code and provides good Error feedback with less code bloat making readability of the overall process a lot better! Oh, and it helps to get your app from a 10K file to a 22K file very quickly ;)
eg. mGetLastError "A call to CreateWindowEx generated the following error.", "CreateWindowEx Error"

Well, if you've gotten this far you're either very bored or cursing me with filling this thread with crap & I'm sorry for the HUGE message!
Hope you enjoy!
Posted on 2003-10-09 12:22:33 by SubEvil
now that is a HUGE post :grin:

anyway, thanks for sharing and I hope to see more of these things posted here.
Posted on 2003-10-10 00:59:23 by TBD
SubEvil,

I haven't looked at your code yet, but just reading your description has got me excited!

Thanks for posting.

farrier
Posted on 2003-10-10 02:12:01 by farrier