4. Suche Tipps und Infos für einen Multiclient TCP Server

Suche Tipps und Infos für einen Multiclient TCP Server

  • ?

    wellnestom schrieb:

    Es werden sich mehrere Clients (0 bis maximal 10) alle 100 bis 500 Millisekunden verbinden, Daten abfragen (nur ein paar Werte), und die Verbindung wieder schließen.

    Da frag ich mich spontan: Warum??? Wäre es nicht einfacher, einfach die Verbindung offen zu lassen?

    0
  • W

    SG1@work schrieb:

    Da frag ich mich spontan: Warum??? Wäre es nicht einfacher, einfach die Verbindung offen zu lassen?

    Ich dachte so wärs einfacher weil das ganze in einem Auto mit WLAN laufen soll und ich mit Verbindungsabbrüchen und derartigen Problemen rechne.

    0
  • K

    alle 100 bis 500 Millisekunden verbinden

    Du must so oder so mit Verbindungsabbruechen rechnen.

    Btw. welche Anforderungen haben fuer TCP gesprochen?

    0
  • W

    knivil schrieb:

    Btw. welche Anforderungen haben fuer TCP gesprochen?

    Von meiner Seite aus nichts. 😉
    Bin neu im Bereich Sockets und hab mir sagen lassen das man UDP nicht benutzen sollte. Deswegen dachte ich an TCP. Wenn du der Meinung bist das UDP sinnvoller ist dann werd ich das machen. Deswegen frag ich hier ja. 😃

    0
  • K

    Wenn du der Meinung bist das UDP sinnvoller ist dann werd ich das machen.

    Ich Weiss nur sehr wenig ueber dein Projekt und die Anforderungen. Die Protokollwahl haengt von Groesse der ausgestauschten Information und dem Kommunikationsprozess ab. Darueber Weiss ich nix, nur du.

    0
  • W

    Folgender Aufbau:
    Ein Raspberry Pi wird als Server in ein (älteres) Auto verbaut und richtet einen WLAN Hotspot ein.
    Über die GPIO Pins werden Geschwindigkeit, Drehzahl, Öldruck usw. gemessen.
    Im Cockpit des Fahrzeugs werden mehrere Android-Tablets verbaut die jeweils bestimmte Werte über WLAN vom RasPi anfordern und Grafisch anzeigen.
    Es werden also maximal 25 Floats vom Server zurückgegeben.

    0
  • K

    Dann packe sie alle in ein UDP-Paket und broadcaste sie dauerhaft im lokalen Netz des Autos. Wer es empfangen will, wird es schon empfangen. Dann ist es auch nicht so schlimm, wenn Pakete verloren gehen, da ja gleich das naechste kommt. Alternativ koennen die Clients auch ein "Ping" senden. Im UDP-Header ist die IP-Adresse des Absenders enthalten, so dass eine Antwort auf das Ping mit den Informationen verschickt werden kann. Da UDP-Pakete ungeordnet ankommen, macht sich ein timestamp oder ein Paketzaehler als Zusatzinformation in deinem Fall ganz gut. Zu beachten ist vielleicht die MTU, um ein splitting zu verhindern. Aber 25 floats und ein uint64_t knacken die garantierte MTU von 512 Byte (?) wohl nicht.

    0
  • W

    Gut, Danke für deine Antworten.
    Dann werd ich mal mit diesem Beispiel rumexperimentieren:
    http://simplestcodings.blogspot.de/2010/08/udp-server-client-implementation-in-c.html

    Kann ich die MTU nicht einfach zur Sicherheit höher stellen? Ich hab auch noch irgendwas im Hinterkopf das man das Fragmentieren der Daten unterbinden kann...???

    Wie würdest du das mit dem Paketzähler umsetzen? Und noch mal ne Dumme Frage: Wenn ich z.B. alle 100 Millisekunden neue Werte Broadcaste, aber erst erst nach ein paar Sekunden die Clients bereit zum empfangen sind, sind dann die zuvor gesendeten Pakete im Datennirvana, oder kann es sein das ich erst noch nen Schwung alter Daten bekomme?

    Gruß Tom

    0
  • K

    Kann ich die MTU nicht einfach zur Sicherheit höher stellen? Ich hab auch noch irgendwas im Hinterkopf das man das Fragmentieren der Daten unterbinden kann...???

    Die MTU ist abhaengig von der Hardware. Wird dein Paket geroutet auf Hardware, die du nicht kontrollierts, bringt dir das setzen der MTU nix. Es kann zu gross sein und es wird gesplittet. Das ist kein Problem an sich und funktioniert ohne zutun. Es erhoeht nur leicht die Wahrscheinlichkeit, dass dein Paket nicht ankommt.

    Wie würdest du das mit dem Paketzähler umsetzen?

    main()
{
  int count = 0;

  while(true)
  {
    read data;
    pack data with count;
    broadcast packed data;
    count++;
  }
}

    Das ist jetzt nur der Broadcastteil. Fuer Konfiguration etc. muss man nicht den gleichen Port/Protokoll nehmen. Da macht es vielleicht Sinn, TCP auf einen anderen Kanal zu verwenden.

    zuvor gesendeten Pakete im Datennirvana

    Wenn Pakete beim Client-PC ankommen und niemand daruf wartet (listen/read), dann werden sie verworfen.

    Btw. ich empfehle nochmals: http://beej.us/guide/bgnet/ auch wenn es vieeeel mehr zu lesen ist.

    0
  • W

    Danke dir. Hat mir viel geholfen!
    Jetzt nur noch eins (oder sollte ich dafür einen neuen Thread aufmachen?):
    C++ kann ja keine Timer Events wie man sie aus anderen Sprachen oder auch aus Qt kennt. Wie schaffe ich es trotzdem einen Thread exakt alle N Sekunden zu starten?

    0
  • ?

    "exakt" geht unter nicht echtzeit-betriebssystemen schonmal gar nix

    0
  • K

    Warum alle 100 MS? Sende sie einfach! Falls Zeit noetig ist, dann benutze einen Timestamp.

    0
Anmelden zum Antworten