Vorgehensweise: Mehrere Datenströme pro Client

  • VB.NET

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von chrixko.

    Vorgehensweise: Mehrere Datenströme pro Client

    Hallo Community!

    Ich habe da ein Problem bei dem ich im Moment ziemlich auf dem Schlauch stehe:

    Beispielsweise: Ich hole mir in regelmäßigen Abständen Daten vom Server wie zum Beispiel Status/Screenshot wie auch immer und möchte währenddessen Dateien hoch-/runterladen. Das Problem hierbei wäre ja, dass es pro Client einen Networkstream gibt und die Daten sich "vermischen" würden und ggf. an den falschen Stream gehen würden.

    Gibt es da eine saubere Lösung für?

    Eine Idee wäre, dass ich jedem Datenpaket einen Headerwert gebe zu welcher "Operation" es gehört und ich dann eine zentrale Klasse habe die erstmal jedes Datenpaket annimmt und je nach Headerwert an die verschiedenen Streams weiter verteilt.

    Ist das eine gängige Lösung oder gibt es da besser Methoden?

    Vielleicht hat jemand einen Denkanstoß für mich. ;)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „chrixko“ ()

    das wäre die meiner Meinung nach beste Lösung, sonst würde es denke ich noch gehen, wenn du einfach sagst, zuerst das Datenpaket der Aktion1 senden/empfangen dann das Paket der Aktion2 usw...
    noch eine andere möglichkeit, wäre für jede "Operation" eine neue Verbindung aufzumachen ;)
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Ja, ähm...um was für einen Server geht es denn? Oder ist das egal?
    Jede TCP-Verbindung, die Du aufmachst ist für sich auch eine total abgeschlossene Sache. Also bei einem Server der mehrere gleichzeitige Verbindungen unterhalten kann, kannst Du natürlich auch von Clientseite aus mehrere Verbindungen öffnen und parallel verschiedene Dinge machen.
    Dein Ansatz bietet sich allerdings ganz klar an wenn: nicht genug parallele Verbindungen hergestellt werden können oder bspw. bei UDP-Verbindungen.

    Gruß FatFire

    Edit: Schon wieder zu langsam. ;(
    @jvbsl:

    zuerst das Datenpaket der Aktion1 senden/empfangen dann das Paket der Aktion2 usw...


    Hierbei denke ich, dass das "managen" der Pakete recht schwierig sein könnte, da zum Beispiel die Aktion "Desktop" empfangen "nie" aufhört und ich Dateien zum Beispiel in 4KB Paketen sende. //Falls ich deinen Vorschlag jetzt richtig verstanden habe.

    @FatFire:
    Der Server kann gleichzeitig mehrere Verbindungen verwalten, die Idee mit den parallelen Verbindungen ist mir auch schon gekommen, jedoch dachte ich mir, dass die Lösung nicht sehr sauber bzw. performant wäre. Brauche ich dann nicht außerdem für jede Operation einen anderen Port?
    die Idee mit den parallelen Verbindungen ist mir auch schon gekommen, jedoch dachte ich mir, dass die Lösung nicht sehr sauber bzw. performant wäre.

    Dazu müsste man wissen, von was für einem Server wir hier reden, wie lange und wie groß der Datenaustausch ist und...also mehr Details, dann kann man bessere Empfehlung abgeben.

    Brauche ich dann nicht außerdem für jede Operation einen anderen Port?

    Ja, aber bei 65k möglichen gehen die Dir nicht so schnell aus :thumbup:
    Ach, und der Serverport den Du ansprichst ist immer der gleiche (sollte es zumindest sein).
    ein Client hat die möglichkeit einen Port mehrmals zu verwenden(der Port 80 fürs Internet kann schließlich auch von 2 Browsern gleichzeitig verwendet werden...)

    Edit: zu langsam, aber richtig :P
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    @FatFire: Es herrscht sozusagen ein ständiger Datenaustausch(von Server zu Client und umgekehrt) und die Größe ist auch variabel von kleinen Nachrichten bis zu ganzen Dateien die aber in zum Beispiel 4KB Paketen gesendet werden.

    Wenn ich das richtig verstehe muss es für jeden Logischen "Client" mehrere TCPClient-Objekte geben. Da pro TCPClient-Objekt nur ein Networkstream vorhanden ist. Sehe ich das richtig?
    Wieviele physikalische Clients hängen in der Regel dran? Wenn das eine überschaubare Dimension ist, dann sehe ich das als nicht ressourcenkritisch an und bin der Einfachheit halber für den Parallelbetrieb.

    Wenn ich das richtig verstehe muss es für jeden Logischen "Client" mehrere TCPClient-Objekte geben. Da pro TCPClient-Objekt nur ein Networkstream vorhanden ist. Sehe ich das richtig?

    Joh.

    Gruß FatFire

    Nachrichten bis zu ganzen Dateien die aber in zum Beispiel 4KB Paketen gesendet werden.

    ankommen tut sowiso das ganze in Blocks die in der Puffergröße festgelegt werden(bzw. auf dem Default Wert sind)d.h. du kannst nicht auf einmal ein Paket in voller größe senden, wenn es den Puffer vergrößert...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    @jvbsl: Ja das ist mir klar. Hab jetzt nur für meine Anwendung einen Wert von 4KB gewählt.

    Es können zwar undefiniert viele Clients am Server "angemeldet" sein, jedoch wird in der Regel die Funktion zum Übertragen von größeren Mengen an Daten und ähnliches nur gleichzeitig für einen Client ausgeführt.

    OK, Danke! Ihr habt mir sehr geholfen. ;)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „chrixko“ ()