Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm using a library called ENet. It is a reliable UDP library.

The way it works is a polled event system like this:

  ENetEvent event;

    /* Wait up to 1000 milliseconds for an event. */
    while (enet_host_service (client, & event, 1000) > 0)
    {
        switch (event.type)
        {
        case ENET_EVENT_TYPE_CONNECT:
            printf ("A new client connected from %x:%u.\n", 
                    event.peer -> address.host,
                    event.peer -> address.port);

            /* Store any relevant client information here. */
            event.peer -> data = "Client information";

            break;

        case ENET_EVENT_TYPE_RECEIVE:
            printf ("A packet of length %u containing %s was received from %s on channel %u.\n",
                    event.packet -> dataLength,
                    event.packet -> data,
                    event.peer -> data,
                    event.channelID);

            /* Clean up the packet now that we're done using it. */
            enet_packet_destroy (event.packet);

            break;

        case ENET_EVENT_TYPE_DISCONNECT:
            printf ("%s disconected.\n", event.peer -> data);

            /* Reset the peer's client information. */

            event.peer -> data = NULL;
        }
    }

It waits up to 1000 milliseconds for an event. If I'm hosting say 75 event driven card games and a lobby on the same thread as this code, will it cause any problems.

If my understanding is correct, the process will simply sleep until there is an event, when there is one, it will process the event then come back here where potentially 5 or so events have queued up since so enet_host_services would return right away and not cause lag.

I have been advised not to use multiple threads, will that be alright like this?

Thanks

share|improve this question
3  
Reliable UDP? That's almost certainly the wrong choice for what you intend to do. You most likely just want to use TCP. –  Lohoris May 13 '12 at 18:52
    
If you aren't using multiple threads, and enet_host_service is a blocking operation, then the server will freeze for up to 1000ms constantly. –  William 'MindWorX' Mariager May 13 '12 at 19:16
3  
@lohiris: while that may be true for this project, there note that "reliable udp" and tcp are not the same things. Tcp is a single channel ordered guaranteed protocol, while udp can be used to implement multi-channel communications where each channel may be ordered and/or guaranteed independently, which is what energy does. Also, even just reimplemenrting tcp in udp has a few advantages, such as being able to work with a stun server for p2p connections behind firewalls without upnp support. –  Sean Middleditch May 13 '12 at 20:15

1 Answer 1

If your entire game is driven by events that come in via enet_host_service, then no, you won't get any delays as a result of this approach. The server may keep sleeping for 1 second but nothing is happening in that period so it doesn't matter.

If however you have any other timed action which happens regardless of which events come in, then they will presumably live outside that switch statement and will have to wait for external events to trigger before the action can execute.

If you are in that situation and do have some other timed events, you can always reduce that 1000ms delay to something smaller, like 50ms, so that the timed events can be attended to fairly regularly. This is unlikely to have a significant negative effect on performance.

Note that you need to wrap the above code in another loop, as enet_host_service will return zero as soon as it manages to go an entire second without getting a message.

share|improve this answer
    
Or just put the event polling in another thread, and it will consume very little of the cpu because of the "sleeps" in the blocking call, and the main thread will be full speed. –  Grimshaw Jun 12 '12 at 23:22
    
True, but that just moves the problem - you still have to get the messages back to and from the network thread, which is non-trivial to do correctly. I guess this is why the original poster stated, "I have been advised not to use multiple threads". –  Kylotan Jun 13 '12 at 12:04
    
Fair enough, then I would suggest to make an intermediate buffer to post/read the packets received. A mutex would solve any syncronization issues, and the first problem would be addressed too :) –  Grimshaw Jun 13 '12 at 13:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.