- Forum
- Windows Programming
- help! <Multithreading> MFC
help! <Multithreading> MFC
I want write an application to manage all process of clients in my classroom (single Server and multiple Clients). But I don't know how to code. I'm a newbie.
Help me!
Help me!
I don't know where to start to code, what library to use, how many class in project ....
My program use client server model. It's use to detect all users (clients) who playing game in classroom. All clients is shown in Server's GUI, look like this http://direct2.anhso.net/original/2/28988/3011201271754851.jpg
When program detect a user is playing game then the icon "computer" in server's GUI will switch to red color. And server can send a message to client.
Thank you so much
When program detect a user is playing game then the icon "computer" in server's GUI will switch to red color. And server can send a message to client.
Thank you so much
One way you could do this, is to have all client apps broadcast (multicast) their statuses.
Your controlling server listens for these updates and renders them on a screen. If it failes to receive a message in some window, it's assumed to be disconnected.
Why do this?
1. This method is stateless, the server and client don't need their own set of protocols and connections.
2. The server doesn't need to keep track of client connections, it just receives updates via UDP that it decodes and displays.
3. The server won't need a whole bunch of threads to track each client.
How would it work? You start a background thread to manage the network comms. That thread just listens for multicast traffic. When it receives something, it decodes it and uses PostThreadMessage to send it to the main thread that the GUI runs on. The main app can manage the display, track which clients are up, time out old clients ... all that stuff.
Where do you begin? Start with an MFC app that can manage the display, has objects to represent clients and their states and receive updates using locally defined messages.
When that is stable, you can start looking at the comms. Stateless UDP stuff is much easier to handle than TCP. It just receives a packet, decodes it and passes it on to the main app (with one of those locally defined messages) or discards it if it's nonsense (with an entry in the application event log).
Your controlling server listens for these updates and renders them on a screen. If it failes to receive a message in some window, it's assumed to be disconnected.
Why do this?
1. This method is stateless, the server and client don't need their own set of protocols and connections.
2. The server doesn't need to keep track of client connections, it just receives updates via UDP that it decodes and displays.
3. The server won't need a whole bunch of threads to track each client.
How would it work? You start a background thread to manage the network comms. That thread just listens for multicast traffic. When it receives something, it decodes it and uses PostThreadMessage to send it to the main thread that the GUI runs on. The main app can manage the display, track which clients are up, time out old clients ... all that stuff.
Where do you begin? Start with an MFC app that can manage the display, has objects to represent clients and their states and receive updates using locally defined messages.
When that is stable, you can start looking at the comms. Stateless UDP stuff is much easier to handle than TCP. It just receives a packet, decodes it and passes it on to the main app (with one of those locally defined messages) or discards it if it's nonsense (with an entry in the application event log).
Topic archived. No new replies allowed.