oscat.lib > oscat.lib fuer CoDeSys 3
Network.lib
mactoolz:
Hi,
ich nochmal zur frühen Stunde,
Ich habe das mir nochmal angeschaut und sehe das hier mit der Mailbox die Verriegelungen für das SysSockRecv gemacht werden.
Ok, also was habe ich geamcht, nachdem ich im Size direkt Daten sehe, habe ich die Mailbox[3] := 1 gesetzt damit im nächsten Zyklus
keine Daten mehr vom Client abgeholt werden.
Jetzt kommt das große aber. Es kommen VIELLEICHT Daten im nächsten Aufruf oder auch nicht.
Sobald ich nach meiner Verarbeitung das Byte wieder zurück setze, kommen meistens keine Daten mehr.
Es sieht so aus das der Client von dem ich die Daten habe möchte die alle irgend wie los geworden ist.
Nur wohnin ???
MacToolz
peewit:
was sind das für daten
welches protokoll wird verwendet
normalerweise ergibt sich das logischerweise ob noch daten kommen oder nicht
du solltest mal die kommunikation mit wireshark aufzeichnen dann sehen wir was sich wirklich aus der leitung tut
mactoolz:
Hi,
also ich verwende das TCP Protokoll. Die Daten sind aus dem Zeichensatz Base64. Aber das wäre doch nicht ganz so wichtig oder.
Ist doch alles Byteorientiert.
Für mich sieht das so aus als würden auch noch Daten kommen, nachdem ich wieder die Freigabe für das SysSockRecv wieder gebe.
Kann das sein das die Puffergröße zu groß ist. Weil der Client weis ja wie groß der Puffer ist (SysSockRecv) und befüllt entsprechend,
das heißt er schaufelt solange rein bis der Puffer Voll ist. Ich unterbreche aber zu früh, zu früh meine ich, das der Client in seiner Abarbeitungszeit z.B. die ersten 100Byte von den Maximal möglichen 1000Byte kopiert hat und somit könnten dann beim nächsten Lesen Daten verloren gehen oder,
weil ich ja das "Size" ablösche.
MacToolz
mactoolz:
Hi,
ich denke das habe ich jetzt im Griff.
Ich bin der Meinung, und das habe ich auch nachgestellt, das wenn der Puffer entsprechend groß gewählt wird, dann wird dieser auch im vollen Umfang befüllt solange Daten kommen.
Das heißt ich muss meinem Puffer klein stellen. Zu einem das intern in der IP_Control der Überlauf eh überwacht wird und das "Size" selber abgelöscht wird,
zum anderen, darf man eigentlich immer bis in die Puffer Grenze laufen. Macht das überhaupt Sinn?
Mir fehlt immer noch das Verständnis wie auf TCP IP Ebene das Abrufen von Daten statt findet. Ich sehe momentan keine schlüssigen Weg für mich.
Was ich auf jeden Fall festgestellt habe ist, das der Client an dem ich mich anmelde und dann den Puffer sehr groß wähle, das er selber in seiner Verarbeitungszeit unterschiedlich große Pakete
in den Puffer sendet.
Was ich gerade selber noch in den Baustein als Test implementiert habe ist,
das wenn ich das Mailbox[3] Byte zum blockieren nehme, da habe ich dann eine neue Methoden Aufrufe genommen die das Betriebssystem anweist
das kein Sende/Empfang Kommunikation zugelassen ist.
--> SysSockShutdown(server_socket, 0);
--> halbes Kommando zurück, diese Funktion ist Systemspezifisch und funktioniert z.B. bei der Wago 750-880 nicht. Andere Zielsysteme wie PLCWinNT habe
ich nicht getestet weil ich zu faul bin. BEi der 750-880 und der RTE kommt vom Shutdown nicht die Rückmeldung das er das ausgeführt hat !!!
Damit funktioniert das ganze meiner Meinung nach besser und flüssiger, ohne das ich selber dann in meinem Code was zusätzlich als verriegelung machen muss,
außer das Byte in der Mailbox zum blockieren zu bringen
Ich bin mal auf deine Antwort gespannt.
MacToolz
peewit:
der standard ist das man daten sendet und aufgrund dessen welche bekommt
und das normalerweise in kleinen datenmengen
kann es sein das du nach dem empfang nicht size = 0 machst ?
denn dann ist logischerweise der puffer irgendwann voll
was für eine kommunikation nutzt du denn nun genau
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln