Netzwerk / Simulation / Updates

Design Patterns, Erklärungen zu Algorithmen, Optimierung, Softwarearchitektur
Forumsregeln
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
Antworten
odenter
Establishment
Beiträge: 207
Registriert: 26.02.2009, 11:58

Netzwerk / Simulation / Updates

Beitrag von odenter »

Hallo,

ich spiele gerade ein bischen mit RakNet rum und habe mir zum Test mal eine Server App und Client App gebaut.
Der Server soll alle 15ms die Simulation updaten, funzt mitm Timer auch ganz gut (ich mache ja noch nix :P ).

Nun sieht meine Hauptschleife im Moment wie folgt aus:

Code: Alles auswählen

  _timer.Start();
  RakNet::Packet *packet = 0;
  DOUBLE timeElapsed = 0;
  while(true)
  {
#if _DEBUG
    // um anwendung anzuhalten wenn ein Client kein heartbeat gesendet hat, um den Client zu debuggen ohne timeout zu bekommen
    this->sendHeartbeat();
#endif

    //! eingehende Packete verarbeiten
    for(packet = _peer->Receive(); packet; _peer->DeallocatePacket(packet), packet = _peer->Receive())
    {
      this->handlePackets(packet);
    }

    // alle 15ms simulation und clients updaten
    timeElapsed += _timer.GetElapsedTimeInMS();
    if (timeElapsed >= 15)
    {
#if _DEBUG
    gf_ODS(gf_ToString(timeElapsed) + L"\r\n");
#endif

      this->updateSimulation(timeElapsed);
      this->updateClients(timeElapsed);
      timeElapsed = 0;
    }
  }
Ich sehe das doch richtig, dass wenn das Lesen der Pakete z.B. nur 7ms dauert, dann würde ich bei dem aktuellen Code genau diese Pakete "verlieren" und nichts damit machen. Was ja nicht richtig wäre.
Das heisst ich müsste alle eingehenden Pakete sowieso erstmal in ne Queue packen und dann verarbeiten?
Oder ist es unrealistisch das so fix gelesen wird?
Oder macht man das grundsätzlich anders?
simbad
Establishment
Beiträge: 132
Registriert: 14.12.2011, 14:30

Re: Netzwerk / Simulation / Updates

Beitrag von simbad »

Ich würde das anders machen.
Du machst zwei queues für die eingehenden Daten. Es wird immer auf der einen geschrieben. Und der eigentliche Verarbeitungsprozess liesst aus der anderen.
Dann brauchst du in deinem Zeitraster, wie groß das auch immer sein mag, immer nur die beiden Queues austauschen.

Der Vorteil ist, du kannst leicht prüfen, ob die Verarbeitung hinterher hängt, dann sind beim Umschalten der Queues noch Nachrichten drin.
Du musst nur das Umschalten synchronisieren. Das bedeutet einmalig Mutex/CriticalSection setzen, umschalten, freigeben. Das macht die Sache verhältnismässig schnell.
odenter
Establishment
Beiträge: 207
Registriert: 26.02.2009, 11:58

Re: Netzwerk / Simulation / Updates

Beitrag von odenter »

Klingt gut, danke.
Ich werde das mal umbauen.
simbad
Establishment
Beiträge: 132
Registriert: 14.12.2011, 14:30

Re: Netzwerk / Simulation / Updates

Beitrag von simbad »

Was ich, um niemanden zu erschrecken, nicht gesagt habe, das sind dann 2 Threads, die da parallel laufen.
Das Programm selbst bildet einen Thread, es muss also ein zweiter gestartet werden.
odenter
Establishment
Beiträge: 207
Registriert: 26.02.2009, 11:58

Re: Netzwerk / Simulation / Updates

Beitrag von odenter »

Das wäre nicht so das Problem für mich.
Hab ich schon vermutet. :)
Antworten