Netzwerkclient zeigt komisches Verhalten

[Vi-P]

Hallo mk-soft danke, dass Du hier für alle ein schönes Beispiel für einen Netzwerkclient gemacht und der Gemeinschaft zur Verfügung gestellt hast. In der PB-Hilfe ist m.E. hier nix zu finden.
Ein paar Dinge sind mir jedoch aufgefallen: (Ist meine Meinung, die auch falsch sein kann)

1. Abgesehen davon, dass der Thread nur einmal verwendet wird, sollte man Variablen (standardmäßig ) im Thread nicht "Protected" sondern besser "Threaded" machen, spart einem spätere Fehlersuche, wenn mal mehr Threads einer Sorte laufen.

2. Um ein Verwenden der gelesenen Daten hast Du dich böse gesagt mit einem ";TODO" gedrückt. Normalerweise wird die Verarbeitung (auch) außerhalb des/der Threads ablaufen (z.B. weil GUI Aufrufe evtl. problematisch sein könnten). Den Zugriff hat man ja über die Struktur ClientData auch im Hauptprogramm. Dann muss ("sollte" im Sinne der Hilfe zu ReceiveNetworkData () ) man sich allerdings noch mit dem Begriff "Mutex" beschäftigen.

3. Der Satz

Bei TCP wird nur gewährleistet das die Daten bis 64kB konsistent in der richtigen Reihenfolge übertragen werden.

ist m.E. gut misszuverstehen. Bis 64k große Blöcke (abzüglich Header) können per TCP als Jumbo-Frames auf einmal versendet werden. Außerhalb des LANs ist die MTU typ. kleiner z.B. 1500. Die einzelnen Pakete können durcheinander, doppelt oder auch mal nicht ankommen. Der "Netzwerkstack" (OSI lässt grüßen) sorgt aber durch eine Nummerierung der Pakete und durch ACK/Resend, dass wenn wir mit einer TCP-Verbindung die Pakete abholen, diese eben schon der Reihe nach ankommen. Der Datenstrom also konsistent aber nicht echtzeitfähig ist. Bei UDP ist das anders.

[mk-soft]

@Vi-P
Du hast dich mit TCP/IP schon beschäftigt. Das freut mich sehr.

Zu 1:
In einer Procedure ist Proteted richtig, da auch bei mehrfacher Verwendung diese jewals einen eigenen Speicherbereich hat.
Threaded ist wie Global, nur das bei Threaded Variablen für jeder Thread einen eigenen Speicherbereich hat.

Zu 2:
Habe mich bei TODO habe ich gedrückt, ist ja nur ein Grundgerüst.
Auf jedem fall solte der Empfangsthread nicht geblockt werden. Entweder die Daten sofort verarbeiten (bei kleinen Mengen), oder mit PostEvent an die GUI senden, oder an einen neuen Thread bei langer Verarbeitung übergeben.

Zu 3:
Ja, es gibt Jumbo Frames, ist aber in den meisten Netzwerken nicht aktiviert.
Über gibt man mit SendNetzworkData einen Datenblock von der Anwendung an den Sendebuffer der größer als die MTU ist , liegt die auch richtig im Empfangsbuffer und kann abgeholt werden.
Übergibt man mit SendNetzworkData mehrere Datenblöcke, kann es aber passieren, das diese nicht in Reihenfolge ankommen. Ein vermischen der Daten der Datenblöcke bei der Übergabe an die Anwendung mit ReceiveNetworkData kommt aber nicht vor, solange es zu keiner Störung in Netzwerk kommt. Daher sollte der Datenblock ausgewertet werden und zum Beispiel wie bei Modbus/TCP einen eigene Daten Header besitzen (Modbus/TCP Header: WORD TransactionID, WORD ProtocolID, WORD DataLen)

P.S.
Vielleicht ist das was für dich ...
Module NetworkTCP

[Vi-P]

Hi mk-soft,

mit TCP beschäftige ich mich seit über 25 Jahren, gibt aber immer noch genügend was ich nicht weiß. Fing damit an, dass ein Kunde Vertriebsbüros mit ISDN Routern vernetzt haben wollte ... . Komm da mal an vernünftige Informationen ohne Google ....

Zu 1: Hast natürlich recht, sonst gäbe es ja auch generell z.B. Probleme mit rekursiven Aufrufen. Verwende in meinen noch kleinen Projekten "Protected" nicht so, meine globalen Variablen sind überschaubar und die Wiederverwendungsquote von Modulen eher gering. Hab mich dann von der Beschreibung in der Hilfe auf die schnelle etwas verwirren lassen. Sollte mir das wie "EnableExplicit" in Projekten auch angewöhnen, um unerwünschte Seiteneffekte auszuschließen.

Zu 2: Irgendein Programmstück muss mal den (Anfang des) Streams verarbeiten und bereinigen. Während dieser Zeit wird kein ReceiveNetworkData () ausgeführt. Egal ob dies im Thread oder anderswo stattfindet. Bin jetzt nicht so der Fan davon event queues zu benutzen. Seit ca. 1 Jahr "weiß man", dass das auch mal schief gehen kann. Ist einfach ein weiterer point of failure, wenn auch ein sehr eleganter.
Zu 3: Darauf, dass Pakete aus unterschiedlichen Sends FIFO weitergeleitet werden, sollte man sich nie verlassen.
Danke für den Link, hatte ich bisher noch nicht entdeckt. Wurde da ein Standard implementiert oder sinnvolles selbst erarbeitet. Unter welcher Lizenz hast Du das gepostet, habe hierzu nix gefunden?

Und noch eine Frage: Wo kann man den "Antrag" zur "Optimierung" des Hilfetextes stellen?

[NicTheQuick]

Und noch eine Frage: Wo kann man den "Antrag" zur "Optimierung" des Hilfetextes stellen?

Schau dir mal die ersten drei angepinnten Threads im Bug-Forum an: viewforum.php?f=20

Oder noch direkter das englische Forum dazu: English Board » Bug Reports » Bugs - Documentation

[mk-soft]

Auf das ClientNetworkEvent must du dich auf die Network Libray von Purebasic verlassen. An sonsten kannst du auch alles über OS API selber programmieren.
Das die Datenübergabe an die Anwendung aus dem Empfangsbuffer stimmt, must du der OS vertrauen, da dies die OS verwaltet. Das ist auch bei API so.

Ich finde es aber blöd (und das bei allen OS), das man keine Kontrolle über den internen Datenstrom (Pakete) des TCP/IP Protokolle hat.

Die Pakete werden intern in der richtigen reihenfolge zusammengesetzt und dann in die FIFO übernommen. Erst wenn dieses fehlt schlägt, bekommt man einen fehler.
Beim ersten Abruf des Empfangsbuffers erhält man mindestens das erste Paket bei nächsten Abruf die folgene Pakete oder einen Fehler.
Aber Achtung! Beim nächsten Abruf des Empfangsbuffers kann neben dem letzen Paket, aber auch schon das nächste erste und folgene Pakete enthalten sein.

Diese verhalten bei Übergabe der Daten an die Anwendung ist bei allen OS so. Das findet ich es etwas nervig.
Leider auch bei der programmierung von SPS Steuerungen mit TCP/IP Kommunikation.


Das Protokoll von Module NetWorkTCP ist eine eigenentwicklung. Die Verwendung von Code aus dem Forum sollte immer ohne irgendwelche einschänkungen frei sein.
Wer das nicht möchte, sollte auch kein Code veröffendlichen.

[Vi-P]

@NicTheQuick: danke, gehe ich die nächsten Tage mal an.

@mk-soft: klar muss man sich immer auf irgendwelche Sachen aus der lib oder dem OS verlassen. Bei event queues habe ich einfach kein gutes Gefühl, ich weiß nur dass im Bereich der Events der Windows GUI immer wieder Glitches gibt. Vielleicht liegt das aber auch gar nicht an den queues selbst. Da habe ich mich einfach noch nicht genügend damit beschäftigt. Und dann geht das halt so wie bei den Eichhörnchen, hat es die erste Nuss geknackt, macht es die anderen genauso auf, auch wenn es andere vielleicht bessere Methoden gibt.

Beim Netzwerk spielt wohl auch viel die lange Historie mit sehr beschränkten Ressourcen (hat man bei den IoTs ja z.T. heute wieder) und natürlich die Interoperabilität der Generationen und verschiedenen Systemen eine Rolle. Leider steht auch auf moderneren Systemen kein höherer Level zur Verfügung, der die Sache so einfach macht, wie eine Datei zu schreiben/lesen.
Man bekommt halt einen Stream, von dem man nie genau weiß, was noch fehlt/nachkommt. Das muss man dann anhand des Inhalts ermitteln ... .

OT: Das mit den SPS kann ich mir gut vorstellen. Echtzeitaspekte gepaart mit proprietärer Implementierung auf SPS Seite. Und dann noch USB Netzwerkadapter am Industrie PC, weil man mehr Schnittstellen braucht und VLAN ja noch nicht erfunden wurde ... . Dazu dann noch RS232, RS485, CAN und Co. damit´s nicht zu überschaubar wird ... .

[RalfP]

>>> 18 Blöcke mit ein paar Bytes und dann ist wieder für 10 Sek. Ruhe. <<<

Hallo Vi-P,

du hast leider nicht geschrieben, ob du die Kontrolle darüber hast, was der ESP8266 genau macht.
Wenn JA, würde ich den ESP8266 so programmmieren, dass bei jedem Frame (der möglichst die 18 Blöcke zusammenfast) am Anfang genau übermittelt wird, wie viele Bytes der Frame enthält (wenn der nicht sowieso immer gleich groß ist).

Ich habe einmal ein Projekt programmiert, bei dem der Datenaustausch ganz ähnlich funktioniert. Dabei gab es keine Probleme wie du sie beschrieben hast. Hier ist der Link:
viewtopic.php?f=11&t=31458
.