Maintaining a userlist with IOCP
Author
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.
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.
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.
Author
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?
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.
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.
Author
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?
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 :-)
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 :-)
Author
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!
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'!!!
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
