Clients der Reihe nach abfragen mit eventueller Wartezeit

  • VB.NET
  • .NET 4.5

SSL ist deaktiviert! Aktivieren Sie SSL für diese Sitzung, um eine sichere Verbindung herzustellen.

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von Marcus Gräfe.

    Clients der Reihe nach abfragen mit eventueller Wartezeit

    Hallo,

    für ein Projekt muss ich ein bestimmtes Verhalten der Teilnehmer im Netzwerk erreichen. Folgendes Problem:

    In einer Simulation habe ich 1 Control Einheit und x Clients.
    Die Control Einheit fragt nun nacheinander alle Clients ab und wartet auf eine Antwort. Wenn der abgefragte Client die Frage erhält sendet er seine Daten an alle Teilnehmer, gefolgt vom einem Endsignal.
    Die Control Einheit nun wartet auf die Daten und das folgende Endsignal. Sofern dieses kommt, soll sie den nächsten Client abfragen. Wenn alle Clients durch sind sendet die Control Einheit ihre eigenen Daten an alle Teilnhemer und das Spiel geht von vorne los.

    Soweit noch kein Problem.

    Auf dem Schlauch stehe ich nun bei der Situation, das der Client nicht antwortet. Wie kann ich es realisieren, das
    a. die Control Einheit x Millisekunden wartet bevor sie den Client erneut versucht abzufragen,
    b. das die Contol Einheit nach x * 2 Millisekunden automatisch den nächsten Client abfragt und
    c. das ganze warten abgebrochen wird wenn der Client antwortet?

    Wenn da jemand eine Idee hat wie sowas funktionieren könnte wäre ich sehr dankbar.
    @Manus Sehr interessantes Problem.
    Von wieviel Clients sprechen wir?
    Erfolgt die Abfrage Client-parallel (in Threads quasi nebeneinander) oder Client-seriell (nacheinander)?
    ====
    Wenn jeder Client beim Server einen separaten Task bekommt, ist das ganze zunächst praktisch unabhängig von der Anzahl der Clients.
    Löse das ganze also zunächst für genau einen Clienten und dann parallelisiere das ganze über Tasks.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!
    Abhängig davon, wie Du die Server-Client-Kommunikation gestaltest, kannst Du entweder das über klassische Threads machen oder mit Async/Await.
    Threads: Senden, Warten und Empfangen der Daten in einem Thread, im Hauptthread eine gewisse Zeit warten und dann schauen, was schneller fertig ist: Der Thread oder das Abwarten. Wenn Thread, dann war alles i.O., wenn das Abwarten, dann war die Kommunikation nicht möglich und der Thread wird abgebrochen.
    m.E. schöner/einfacher/moderner: Async/Await. Da gibt es auch ein schönes MSDN-Beispiel
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von VaporiZed, mal wieder aus Grammatikgründen.

    ― Eine häufig von mir verwendete Abkürzung: CEs = control elements (Labels, Buttons, DGVs, ...)
    ― If Not GrammarIsOk() Then AssumeThatCodeIsOk = False
    ― »Oh, großes Spaghetticodemonster. Bitte schicke mir Durchblick! Oder zumindest eine Gabel. Oder – wenn es kein Besteck mehr gibt – zumindest Glasnudeln.«

    RodFromGermany schrieb:

    @Manus Sehr interessantes Problem.
    Von wieviel Clients sprechen wir?
    Erfolgt die Abfrage Client-parallel (in Threads quasi nebeneinander) oder Client-seriell (nacheinander)?
    ====
    Wenn jeder Client beim Server einen separaten Task bekommt, ist das ganze zunächst praktisch unabhängig von der Anzahl der Clients.
    Löse das ganze also zunächst für genau einen Clienten und dann parallelisiere das ganze über Tasks.


    Anzahl der Client kann Variieren, wobei der Control Rechner aber die Teilnehmer kennt. Und diese werden seriell abgefragt, sprich der Control Rechner fragt immer nur einen Client ab, dann den nächsten entweder nach Zeit oder nach der Antwort. Das ganze wird via SIMPLE Protokol gemacht wobei nach meiner Plannung der Control Rechner die Abfragen via UDP Broadcast an die Clients schickt und die auch via UDP Broadcast antworten (Ob ein Client angesprochen wird steht im SIMPLE Protokol drin). Ich weiß, TCP wäre sicherer was den Empfang bestrift und die Rückmeldungen aber das ganze Simuliert einen Datenaustausch via Funk, auch ab kommt es zu Verlusten.


    VaporiZed schrieb:

    Abhängig davon, wie Du die Server-Client-Kommunikation gestaltest, kannst Du entweder das über klassische Threads machen oder mit Async/Await. Threads: Senden, Warten und Empfangen der Daten in einem Thread, im Hauptthread eine gewisse Zeit warten und dann schauen, was schneller fertig ist: Der Thread oder das Abwarten. Wenn Thread, dann war alles i.O., wenn das Abwarten, dann war die Kommunikation nicht möglich und der Thread wird abgebrochen.m.E. schöner/einfacher/moderner: Async/Await. Da gibt es auch ein schönes MSDN-Beispiel
    Danke, damit werde ich mich morgen mal beschäftigen.
    @Manus Broadcast ist hier suboptimal.
    Das wird üblicherweise versendet, um alle Clients gleichzeitig anzusprechen, z.B. um überhaupt einen Client zu suchen oder um einen TV-Stream zu übertragen, wo es halt auf Sicherheit nicht ankommt.
    Du solltest schon mit jedem Client einzeln per TCP kommunizieren, da kannst Du das ganze parallelisieren. Darauf würde ich jetzt mein Hauptaugenmerk drauf legen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!
    @Manus Bitte demnächst sparsamer zitieren (siehe Boardregeln zum Thema Voll-Zitate). Danke.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum