Sign in to follow this  
Crazyfool

Maintaining a userlist with IOCP

Recommended Posts

Hi, I have been attempting to work this out for awhile, but even after I get advice, I still take blind shots at how to solve this. Anyway, I am working with the Microsoft SDK IOCP sample iocpserverex.cpp, and I got it to run fine. I then got it to parse data, respond accordingly, etc, but it can only echo back to the user who sent it. I want to be able to send data to clusters or all of the users when recieving certain data, for instance, a chat server. I understand the logic behind it; Have an array(or vector, or whatever) of clients, and cycle through them and for each connected or active one, send the message. Side note: I rewrote the entire code in attempt to understand the usage of various structs, but no dice.

Share this post


Link to post
Share on other sites
So, create a collection of all connected clients. When you want to echo a message, loop over this collection, and send a message, to each of the clients. You already know how to send a message to a client, right?

The only thing you need to be careful about is that you need one OVERLAPPED structure per outstanding message per client, which means a lot of OVERLAPPED structs.

Share this post


Link to post
Share on other sites
Yep, but the 2nd part is a partial answer to my question. What else do I need to "hold"; can it be pretty much up to me how its done, or should I just use the struct the example uses (which I'm not sure how to use it, they have CtxtList (linked list) but I'm not sure how to work with it) and what do you mean about the overlapped. Do you mean every message has to use an entire new one, or just one per client?

Share this post


Link to post
Share on other sites
You can manage the OVERLAPPED structures any way you want.

You need one valid, non-moving OVERLAPPED structure per currently outstanding request. If you have three clients, and one client has one outstanding read request, one client has one outstanding read and one outstanding write, and the last client has one outstanding read and three outstanding writes, you would need (1+0 + 1+1 + 1+3) OVERLAPPED structures.

However, given the problems you're describing with adopting the sample code, it suggests to me that you're not yet mature enough in your programming that you can make effective (and safe!) use of OVERLAPPED I/O. It's really quite a scary topic, with lots of pitfalls that aren't obvious (or even visible) to the naked eye.

Share this post


Link to post
Share on other sites
Ok, thanks! However, what do you suggest I do? I have spent some time going around trying to find good reads, but perhaps I am not looking hard enough. I have the book Network Programming for Microsoft Windows, and I have through it (more like skim), so I'll look through that with much more care. Any more suggestions?

Share this post


Link to post
Share on other sites
To get better: Write lots of code! And actually debug it under heavy load.

Run it on computers other than your own. Read (and debug!) lots of other people's code.

Overlapped I/O is a form of threading, and most people don't have enough design experience with threading to do it right -- they either over-synchronize, or suffer from race conditions. Doing it right comes from experience -- the kind of experience that make you able to dive into someone else's code and figure out what's going on.

Ideally, if you want to become a good systems and networking programmer, you get involved in some open source application project that uses threads and networking, and study the code, start fixing bugs/contributing, and discuss with other developers on that project. I really can't recommend that method enough; I find it far superior to books and home-study.

To "get" the specific case of OVERLAPPED structures: find at least three totally separate sample programs on the web that use it, and study them. Set breakpoints in the queue and service functions, and step through them. Figure out how they tick. I bet you, at least one of those three will actually have a bug -- if you can figure out which one, you're well on your way :-)

Share this post


Link to post
Share on other sites
Awesome; And I dont want to become a great networking programmer per se, but if I wrote off networking as "not for me" without getting down and dirtier than the simple networking, I'd be doing an injustice to myself. Right now it seems very interesting, and when it does all come together, it should be very rewarding. Thanks much!

Share this post


Link to post
Share on other sites
hey! who do you think you're talking to, hplus06? (more like h MINUS 0603!!! ha ha, i'm lonely :(...) crazyfoo' is plenty "mature" enough to comprehend ___OVERLAPPED____! stuctures (what's the deal with the emphasizing?). cwazyfoo is the most smarterest guy i know, you're just jealous that his immense talent eclipses all our pathetic attempts at what we call programming. i worship him like a god (second to hare krishna) and only wish i had half the skills as him. you think you're so grand because you can talk about theses concepts you can't even explain (probably because you don't grasp them either!) so get off your high horse and give the craziest foo' i know some props! I PITY DA CRAZY FOO'!!!

Share this post


Link to post
Share on other sites
When you receive your message to notify registered clients, loop through your array and create a write message for each of those clients.

An example would be:

1. Received message to send (your handler has been called).
2. Handler routine requests a read lock on the client list.
3. Loop through the client list and find anyone interested in notification.
4. for each client create a new overlapped IO structure and fill it in.
5. post your write operation to the IOCPort.
6. release your read lock on your client list.

Locking your client list is very important since you could have people registering with your service at any time. Creating a Read/Write Lock would be an even better idea than critical sectioning. Here is my post on a builtin but unsupported RW lock in WinNT and later.

IOCPorts are also prone to race conditions where you have threads waiting on other threads which will stall or, more than likely, kill your service completely. The best methodology is to do as little as possible in your event handlers.

Good luck with this. IOCPorts is a rough road but if you can master it, you have a huge jump on other socket/file programmers.

Happy coding.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this