Ahhhh GetCurrentThreadId(), that''s the ticket.
Thanks guys. The way I am doing it inside of the class is working quite nicely and is very compact and quite elegant IMO. But of course I have to be biased towards my own code don''t I?
I''m just learning as I go here and I must say it has been a heck of a learning experience so far.
Hopefully I''ll get to share the results with you all when it''s done. Maybe in the form of a nice tutorial or something. At that time I think my overall reasoning for this setup will become more clear. Then again, maybe once I start stress testing it, it will fall all the pieces
By the way, the queue is getting protected with critical sections. I lock it when I need and release it when I don''t. Basically, each thread does 2 things. 1) Check the queue for a packet and pop it off if necessary and 2) send the packet over the network. This requires me to lock data in two particular places. However, at the same time, it should allow me to begin servicing a second packet as soon as the first thread is done with the queue and is waiting to be sent. That''s the theory anyway.
The end code will hopefully be very robust as I begin adding checks for all necessary error conditions and such. With any luck and more help from you fine fellows (and possible ladies out there?) this will turn out quite nice.
Aside from that, it''s a generic object all to itself. If you don''t want a threaded server it''s a simple matter of initializing the network object that way and it knows what to do from there. All the user needs to do is create an instance of it with the desired parameters and then only process the packets it gives you and push on packets to it for sending. Everything else is done behind the scenes and the user hopefully will never know it''s even there.
The object uses no game code whatsoever so in theory it can be used in pretty much any application. In theory
Thanks all,
Webby