oscat.lib > oscat.lib fuer CoDeSys 3

Network.lib

<< < (8/8)

peewit:
ich habe irgendwie den faden verloren

über die sps (immer 100 bytes ..) funktioniert es
aber über den client geht es nicht

(welcher client ?)


vielleicht kannst du deine erkenntnisse nochmals kurz zusammenfassen

du musst berücksichtigen das andere deinen wissenstand nicht haben und es so sofort zu missverständnissen kommt.

mactoolz:
Hi,

also meine test waren folgende.

Nachdem dieser Client sich seltsam verhält, habe ich eine Socket Verbindung zu einen Software TCP Server erstellt.
Da verhält sich der Socket, sprich das empfangen der Daten so wie man es zu erwarten hat.

Und zwar, man geht davon aus und das ist auch der normale Fall, das wenn Daten über das SysSockReceive kommen, diese direkt aus dem Puffer zu verwenden und auch zu kopieren.
Das heißt wenn der Puffer größer ist als das was wirklich gesendet wird, sendet der Server seine Pakete vollständig und es können alle direkt entnommen werden.

Der Test sah so aus, 100Byte gesendet, 100Byte kamen in der Steuerung an und wurden dann von mir ausgewertet.

So, jetzt der extrem Fall, ich habe auf dem SysSockReceive ein Breakpoint gesetzt, die SPS steht, der TCP Server sendet jetzt mehrfach 100Byte hintereinander,
sprich lasse ich dann das SysSockReceive durchlaufen, kommen genau alle diese Daten in der Anzahl richtig in die Steuerung.

Also ein ganz normales Verhalten.

Jetzt zu dem komischen Client. Ich habe noch festgestellt das dieser zwischen seinen Daten eine Pause einlegt.
Es gibt aber in seinem Protokoll kein STX/ETX.

Sobald ich mich verbinde sendet er alles was er hat, nur halt zeitlich versetzt. Das heißt der SysSockReceive meldet dann auch mal ein paar Zyklen (-1) kein Daten.

Damit ich alles von diesem Client Daten bekomme und auch vollständig, musste ich einen Timer einsetzen.
Dieser Timer prüft dann das bei (-1) n-Sekunden keine Daten mehr kommen, das er auch wirklich alles gesendet hat.

Das funktioniert auch soweit. Genau das was im WireShark steht, sind genau die Daten die ich dann auch in der Steuerung im Ascii Zeichensatz
lesen kann.

Für mich stellt sich gerade die Frage ob wir dem noch nachgehen sollen, aus reinem Interesse oder wir das einfach lassen, weil es geht mit regulären Client
die das sehr vernünftig machen.

Ich denke eher schon. Belassen wir das Thema, schließen das ab, weil der Code funktioniert einwandfrei.

PS: Ich komme gleich aber mit einem anderem Thema ... :-) ...

Danke ...


MacToolz

peewit:
wenn die daten keine segementierung haben sondern eigentlich ein zusammenhängender datenstrom
dann gibt es logischerweise das problem des erkennens wann es zu ende ist.

im normalfall spielt das keine grosse rolle da fast alle geräte heutzutage einen ausreichend grossen puffer zur verfügung stellen. also speicher im überfluss.

das ist bei einer sps leider anderes, sehr wenig speicher und schlechte arbeitsbedingungen, da eine sps ursprünglich für andere zwecke entwickelt wurde und die file und ethernet kommunikation eigentlich erst nachträglich hinzugefügt wurden.

wenn keine echtes ende vorhanden dann musst du mit timer oder ähnlichen unschönen dingen arbeiten.


streng genommen sollte dein buffer groesser sein als die menge an daten die als datenstrom kommen können.

mactoolz:
Hi,

die Bedingungen einer SPS sind schon klar. Das Verhalten ist aber zu diesem client anders.
Ich habe das schon geschrieben das ein anderer Client sich ganz normal verhält wie man es erwartet.

Das hier kein STX/ETX vorhnden ist, ist nicht die Frage oder Aufgabe. Es geht um die Tatsache das wie im ersten Ansatz sich auf dem TCP IP Protokoll irgendwie anders verhält als man erwartet.

Gut belassen wir es dabei so wie es ist. Es verhält isch alles ganz normal. Der Socket funktioniert wie zu erwarten.
Warum der Client sich so seltsam verhält kann ich nicht sagen ...

Danke und bis dann ...

PS: Schau mal in das Base64 Post rein ... :-) ... da geht es weiter ...


MacToolz

Navigation

[0] Themen-Index

[*] Vorherige Sete