mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Handshake das auf TCP aufsetzt


Autor: Torsten Albrecht (torsten_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich suche nach einem einfachen standardisierten Handshake Protokoll, das 
auf TCP aufsetzt. Ich habe folgendes Problem:

Mein TCP-Server (HW: Mikrocontroller von Atmel) liest Kommando-Strings 
aus dem RX-Buffer des Ethernet-IC (LAN IC W5100 von Wiznet) aus, setzt 
die Aufgabe um und antwortet dem TCP Client (GUI) gegebenenfalls. Da 
entsteht auch schon mein Problem, weil die Kommunikation ohne feste 
Wartezeiten realisiert werden soll. Dem Client fehlt die Information 
wann er mit dem Senden des nächsten Befehls beginnen kann. – Wie bereits 
erwähnt soll hier keine feste Wartezeit von einigen ms eingefügt 
werden!- Wenn nach jedem Kommando eine Antwort gesendet würde, wäre es 
ja auch kein Problem, das ist aber leider nicht der Fall, da auch reine 
Setzbefehle vom Client gesendet werden sollen, auf die der Server nicht 
antwortet. Nebenbei: der TCP-Client wurde in LABView realisiert.
Momentan treten immer Fehler auf, wenn die „Ping“-Zeiten größer als die 
Wartezeit oder bzw. wenn es im LAN zu Übertragungspausen kommt, die 
größer als die Wartezeit sind.

Ich suche nach einem standardisierten Protokoll, das den 
Übertragungsvorgang durch unmittelbare Quittungssignale synchronisiert.

Beispiel: Ein Sender signalisiert Sendebereitschaft, wenn Daten gesendet 
werden sollen, ein Empfänger signalisiert Empfangsbereitschaft, wenn er 
neue Daten verarbeiten kann oder möchte. Ist sowohl Sendebereitschaft 
als auch Empfangsbereitschaft hergestellt, beginnt die Datenübertragung.

Ich habe mir ein eigenes Handshake-Verfahren überlegt, das über einen 
zusätzlichen Port agiert. Das funktioniert auch super, die Wartezeiten 
sind dann auch überflüssig!!! Aber wie gesagt es muss zwingend ein 
standardisiertes Protokoll bzw. Verfahren sein.
Oder vielleicht findet sich meine Überlegung auch in einem Standard 
wieder, das würde mir ebenfalls genügen! Deshalb hier mein Ansatz:
Ein zusätzlicher Socket (Port+IP) wird als Steuerleitung verwendet: Der 
Client sendet einen Befehl zum Server. Nachdem der Server den kompletten 
Befehl ausgelesen und verarbeitet hat, wird ein ACK-String zum Client 
gesendet. Nachdem der Client den ACK-String ausgelesen hat, kann er 
entweder damit beginnen die Antwort auf seine Anfrage auszulesen, oder 
den nächsten Befehl zum Server zu senden. (Wenn nach einer Zeit x s kein 
ACK gelesen wurde, wird die Verbindung neu aufgebaut.)

Weitere Bemerkungen:
- Der Ethernet-IC von Wiznet unterstützt nur TCP und UDP.
- 4 Sockets können frei verwendet werden.
- TX-Buffer bzw. RX Size kann auf 2/4 kB gesetzt werden
- TCP Handshake endet am Wiznet-IC -> daher habe ich keine Möglichkeit
  die Übertragung zu blockieren
- disconnect/connect der TCP-Verbindung nach jedem Befehl würde zu
  lange dauern

Kann mir jemand weiterhelfen????? Ich danke schon mal im Voraus!

Autor: juppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>- TCP Handshake endet am Wiznet-IC -> daher habe ich keine Möglichkeit
>  die Übertragung zu blockieren

Ist auch besser so!

Autor: Nosnibor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten Albrecht schrieb:
> Ich suche nach einem standardisierten Protokoll, das den
> Übertragungsvorgang durch unmittelbare Quittungssignale synchronisiert.

Also eigentlich leistet TCP das schon alles (Flußkontrolle), geht aber 
vielleicht von anderen Voraussetzungen aus...


> Dem Client fehlt die Information
> wann er mit dem Senden des nächsten Befehls beginnen kann.

Was spricht gegen "jetzt sofort"? Soll der Client den Befehl doch 
senden, sobald er ihn fertig hat. Wenn der Server ihn noch nicht 
verarbeiten kann, läßt er ihn eben so lange im Wiznet-Chip liegen. Bevor 
der Wiznet-Chip an aufgestauten Befehlen erstickt, wird er das mit dem 
TCP-eigenen Standardverfahren (Stichwort "window size" bzw. "receive 
window") signalisieren, und das Client-TCP muß sich dann eben 
zurückhalten und die Befehle selber speichern.

Ein Problem entsteht nur, wenn der Client die Befehle dauerhaft 
schneller sendet als der Server sie verarbeiten kann (z.B. Client sendet 
jede Sekunde einen Setzbefehl, für den der Server 1,1s zur Ausführung 
braucht). Dann muß irgendwann mal ein Befehl übersprungen werden.
Drei Lösungsansätze:

 - der Server macht das, d.h. wenn er einen Setzbefehl aus dem Wiznet 
geholt hat, und es steht noch mehr drin, ignoriert er ihn. Ist irgendwie 
bescheuert, weil man sich dann das TCP genausogut sparen könnte.

 - man spart sich das TCP und nimmt UDP stattdessen. UDP eignet sich gut 
zum Ignorieren von Daten, wenn man gerade keine Zeit hat.  :)  Ist 
allerdings blöd, wenn der Client auf eine Antwort wartet, und der Server 
hat ausgerechnet diesen Befehl gerade ignoriert...

 - der Client nimmt Rücksicht, indem er gelegentlich (z.B. nach je 10 
Setzbefehlen) einen Befehl sendet, auf den er eine Antwort bekommt, und 
dann auch auf die Antwort wartet, bevor er mit seinem Monolog 
weitermacht. Die meisten Protokolle sehen ja irgendein "ping" oder "echo 
request" oder sowas vor, das dem Server keine Arbeit macht, und dem 
Client sagt, daß der Server noch lebt.

Autor: Torsten Albrecht (torsten_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Nosnibor,

vorab vielen Dank für das aufmerksame Lesen und deine Überlegungen.

Torsten Albrecht schrieb:
> Dem Client fehlt die Information
> wann er mit dem Senden des nächsten Befehls beginnen kann.

Nosnibor schrieb:
> Was spricht gegen "jetzt sofort"? Soll der Client den Befehl doch
> senden, sobald er ihn fertig hat. Wenn der Server ihn noch nicht
> verarbeiten kann, läßt er ihn eben so lange im Wiznet-Chip liegen. Bevor
> der Wiznet-Chip an aufgestauten Befehlen erstickt, wird er das mit dem
> TCP-eigenen Standardverfahren (Stichwort "window size" bzw. "receive
> window") signalisieren, und das Client-TCP muß sich dann eben
> zurückhalten und die Befehle selber speichern.

> Ein Problem entsteht nur, wenn der Client die Befehle dauerhaft
> schneller sendet als der Server sie verarbeiten kann (z.B. Client sendet
> jede Sekunde einen Setzbefehl, für den der Server 1,1s zur Ausführung
> braucht). Dann muß irgendwann mal ein Befehl übersprungen werden.

Genau das ist mein Problem, wenn der Client dem Server mit Kommandos 
„bombardiert“ und der Server diese nicht in der kurzen Zeit verarbeiten 
kann, füllt sich der RX Buffer des Wiznet IC’s. Zudem muss zwingend nach 
einer Frage auch die Antwort gelesen werden können, bevor der nächste 
Befehl an den Server gesendet wird.

> Drei Lösungsansätze:

>  - der Server macht das, d.h. wenn er einen Setzbefehl aus dem Wiznet
> geholt hat, und es steht noch mehr drin, ignoriert er ihn. Ist irgendwie
> bescheuert, weil man sich dann das TCP genausogut sparen könnte.

Das wurde zur Sicherheit schon so von mir implementiert, ist aber leider 
keine Lösung für mein Problem da alle Befehle ausgewertet werden müssen.

>  - man spart sich das TCP und nimmt UDP stattdessen. UDP eignet sich gut
> zum Ignorieren von Daten, wenn man gerade keine Zeit hat.  :)  Ist
> allerdings blöd, wenn der Client auf eine Antwort wartet, und der Server
> hat ausgerechnet diesen Befehl gerade ignoriert...

UDP bietet sich hier ohne ein weiteres Protokoll, das die sichere 
Datenübertragung garantiert und Flusskontrolle überwacht, nicht an.

>  - der Client nimmt Rücksicht, indem er gelegentlich (z.B. nach je 10
> Setzbefehlen) einen Befehl sendet, auf den er eine Antwort bekommt, und
> dann auch auf die Antwort wartet, bevor er mit seinem Monolog
> weitermacht.

Eine feste Struktur wie 10 Setzbefehle und anschließend einen Befehl mit 
Antwort soll es ebenfalls nicht geben.

> Die meisten Protokolle sehen ja irgendein "ping" oder "echo
> request" oder sowas vor, das dem Server keine Arbeit macht, und dem
> Client sagt, daß der Server noch lebt.

Den sogenannten „Heartbeat“ könnte man mit dem fehlenden ACK-Response 
erschlagen. Wenn bis zu einem Timeout kein ACK vom Server empfangen 
wurde, dann blockiert vermutlich der Socket und über einen weiteren 
Socket könnte der Server neu initialisiert werden.
Ich suche nach einem bekannten Verfahren bzw. standardisierten 
Protokoll, dass so ein ACK-Response oder ähnliches enthält (für 
Flusskontrolle), welches ich dann im Mikrocontroller per Software 
realisieren kann.

Autor: Thomas S. (klegom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten Albrecht schrieb:
> ich suche nach einem einfachen standardisierten Handshake Protokoll, das
> auf TCP aufsetzt.

TCP hat einen Handshake.
Der Wiznet beherrscht das auch (hoffentlich)

Wenn man dem Wiznet die eingehenden Daten nicht quittiert macht er 
Handshake über TCP und der Server kann nicht weiter senden.
Dies ist auch gleichzeitig das "Standardisierte" verfahren.

Ich benutze den Wiznet auch. Man kann die Daten im Ring Buffer lesen, 
ohne sie zu quittieren (Kommando Sn_CR_RECV). Quittieren darf man sie 
erst später, wenn man der Gegenseite signalisieren will, dass sie weiter 
machen darf.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ich suche nach einem einfachen standardisierten Handshake Protokoll, das
>auf TCP aufsetzt. Ich habe folgendes Problem:

hat TCP schon eingebaut. Die Flusskontrolle geht ueber das window-size 
Feld.

> Dem Client fehlt die Information
> wann er mit dem Senden des nächsten Befehls beginnen kann.

Ich nehme an, die Anbindung geht via Serielle? Keine CTS/RTS Leitungen
(fuer die Flußsteuerung) ?

> Nebenbei: der TCP-Client wurde in LABView realisiert.
> Momentan treten immer Fehler auf, wenn die „Ping“-Zeiten größer als die
> Wartezeit oder bzw. wenn es im LAN zu Übertragungspausen kommt, die
> größer als die Wartezeit sind.

-v -v -v !!!
Fehler: auf welchem Layer kommen die Fehlermeldungen? Hat die 
Applikation
einen Timeout eingebaut? ICMP echos sind das erste, was ein 
ueberlasteter Router
wegschmeisst; keine gute Idee (vorausgesetzt, die Anwendung soll nicht 
nur
im lokalen Netz "funktionieren")! Was macht das ping genau?

Kannst Du einen tcpdump anfertigen?

>Ich habe mir ein eigenes Handshake-Verfahren überlegt, das über einen
>zusätzlichen Port agiert.

Da dreht sich einem Firewall-Admin der Magen um. Um die Loesung 
vollkommen
ungeeignet fuer einen betrieblichen Einsatz zu machen, kann man noch 
dynamisch
den Port in der ersten Verbindung aushandeln (a la ftp) ;-)

> Das funktioniert auch super, die Wartezeiten
>sind dann auch überflüssig!!! Aber wie gesagt es muss zwingend ein
>standardisiertes Protokoll bzw. Verfahren sein.

Empfehlung: erst auf Layer1-4 das (moegliche) Netzwerkproblem 
analysieren.
-> tcpdump.
Eine perfekte Flußsteuerungsloesung wurde bereits im TCP Protokoll 
entwickelt.
Wenn da etwas mit dem Wiznet nicht stimmt, wuerde ich ein Ticket
beim Hersteller aufmachen.

> - TCP Handshake endet am Wiznet-IC -> daher habe ich keine Möglichkeit
>  die Übertragung zu blockieren

nochmal: keine (seriellen) Handshake-Leitungen? Sind diese richtig 
programmiert??
Ein Logikanalysator(LA) vorhanden? Hat der LA absolute Timestamps 
("abgeglichen"
zum tcpdump?)

>disconnect/connect der TCP-Verbindung nach jedem Befehl würde zu
>  lange dauern

Ack! Ein ordentlicher TCP Stack hat fuer neu aufgemachte 
TCP-Verbindungen
ein slow start Verfahren, was sich langsam an die zur Verfuegung 
stehende Bandbreite
"rantastet".

VG,
Hans

Autor: Nosnibor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgenwie kommen mir die Anforderungen widersprüchlich vor. Also habe ich 
sie wahrscheinlich nicht richtig verstanden.      :)

Wenn der Client sowohl einen Riesenhaufen Befehle auf einmal loswerden 
als auch zu jeder Zeit schnell Antwort bekommen will, ist eine zweite 
TCP-Verbindung für "dringende" Befehle/Fragen vielleicht gar nicht so 
schlecht. Der Server muß dann eben immer die "dringende" Verbindung 
zuerst bearbeiten, und erst wenn dort nichts mehr anliegt, hat er Zeit 
für die "normalen" Befehle auf der anderen Leitung. Für die "dringende" 
Verbindung hat TCP noch das PUSH-Bit, damit Daten sofort weitergereicht 
werden, anstatt zu warten, bis ein größeres Paket zustandekommt.

Wenn es jedoch darum geht, den Client in seinem Monolog zu bremsen, 
damit er nachher nicht denkt, der Server sei kaputt, nur weil der erst 
noch den Rückstand aufholen muß... das ist irgendwie blöd, da muß man 
TCP geradezu sabotieren, denn eigentlich ist es ja gerade die Aufgabe 
von TCP, die Nutzer nicht mehr damit zu behelligen, wann wieviele Bytes 
wo angekommen sind.

Man kann jetzt versuchen, den Sendepuffer im Client und den 
Empfangspuffer im Wiznet möglichst klein zu machen, so daß der Rückstau 
mit TCP-Mitteln schnell beim Client ankommt.

Oder man kann ein Protokoll dazwischenschieben, das für jeden Befehl 
eine Bestätigung fordert. Die meisten derartigen Protokolle sind aber 
totaler Overkill und oberhalb von TCP fehl am Platze, weil sie das halbe 
TCP ersetzen könnten. Sinnvoll wäre es, einfach festzulegen, daß jeder 
Befehl vom Server zuerst mit einem Bestätigungsbyte beantwortet werden 
muß, und danach kommt dann, falls vorgesehen, die eigentliche Antwort. 
Aber das ist so trivial, daß es dafür bestimmt keinen Standard gibt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daumenregel:
- Entweder man kommt mit dem Prinzip von TCP zurecht.
- Oder man streicht TCP und setzt auf UDP (plus evtl. irgendwas drauf).

TCP zu vergewaltigen indem man das halbe TCP obendrauf nochmal 
realisiert, nur ein bischen anders, sorgt allzu leicht für Probleme. 
Zwei Kanäle permanent offen zu halten, weil man mit einem nicht 
auszukommen meint, sorgt für wechselseitige Missverständnisse, halb 
offene Verbindungen mit minutenlangen Timeouts während denen garnichts 
mehr geht und Zoff mit Filtern und Firewalls.

Ich habe die Anforderungen hier nicht so recht verstanden, vor allem 
nicht warum sich das mit den gängigen Möglichkeiten von TCP beisst. Aber 
was ich aus Erfahrung weiss: TCP ist nicht in jedem Fall besser als UDP, 
auch wenn sich das Einsteigern anfangs automatisch so darstellt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anzumerken wäre evtl. noch, dass die üblichen TCP Sockets eine optionale 
out-of-band Signalisierung kennen. Wie sich das beim Wiznet darstellt 
habe ich grad nicht parat.

http://docs.hp.com/en/B2355-90136/ch03s07.html

Autor: Torsten Albrecht (torsten_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nosnibor schrieb:
> Man kann jetzt versuchen, den Sendepuffer im Client und den
>
> Empfangspuffer im Wiznet möglichst klein zu machen, so daß der Rückstau
>
> mit TCP-Mitteln schnell beim Client ankommt.

Hat jemand eine Idee wie man den TCP TX Buffer verkleinern kann? (Mein 
Client wurde in LabVIEW realisiert!)

Der RX-Buffer des Servers ist 2048 Bytes groß. Der TX Buffer des Clients 
ist wahrscheinlich 10240 Bytes groß. (Bei einem Test zeigte sich, dass 
wenn der Server keine Daten aus dem RX Buffer ausliest, erst nach 10240 
gesendeten Bytes die Meldung kommt, dass keine weiteren Daten mit dem 
LabVIEW TCP write VI gesendet werden können.) Wie kann ich den TX Buffer 
auf beispielsweise 2048 Bytes reduzieren? Ist das überhaupt möglich?

Das würde mir schon etwas weiterhelfen!!

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versteh überhaupt nicht, was Du überhaupt willst. Irgendwie habe ich 
den Eindruck, dass Du essentielle Konsequenzen von Netzwerkverbindungen 
nicht verstanden hast.

Einige sind z.B.:

 - Es gibt überhaupt keinerlei Garantien wann und wie schnell Deine
   Daten beim Empfänger ankommen.

 - TCP ist ein sequentielles FIFO-Protokoll. Was als erstes gesendet
   wird, bekommt der Empfänger als erstes

 - Eine TCP-Verbindung besteht aus zwei "Kanälen". Die Sende-Richtung
   und die Empfangs-Richtung. Beide Kanäle sind zeitlich in keiner
   Weise miteinader korreliert.

Gegen diese Grundsätze kannst Du nicht ankämpfen. Wie gesagt, Dein 
Problem ist völlig unverständlich.

Meine Vermutung ist, weil das Stichwort GUI gefallen ist, dass Du Dich 
mit Nebenläufigkeit und Pipelineing beschäftigen solltest.

Du hast vermutlich kein TCP-Problem, sondern ein grundsätzliches 
Programmier-Verständnis-Problem.

Autor: Udo R. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unbekannter schrieb:
> Ich versteh überhaupt nicht, was Du überhaupt willst. Irgendwie habe ich
> den Eindruck, dass Du essentielle Konsequenzen von Netzwerkverbindungen
> nicht verstanden hast.

Jep sehe ich irgendwie auch so.
Zum einen sagt der TE:
> Dem Client fehlt die Information wann er mit dem Senden des nächsten
> Befehls beginnen kann.
Zum anderen:
> Zudem muss zwingend nach einer Frage auch die Antwort gelesen werden
> können, bevor der nächste Befehl an den Server gesendet wird.

Dann mach doch genau das:
Der Client sendet einen Request und dann wartet er auf die Antwort. Das 
Warten kann man normalerweise mit einem Read mit timeout problemlos und 
ohne den Rechner zu belasten tun.
Und wenn man derweil was anderes machen will, dann muss man eben 
multithreaded programmieren, das heisst in dem Fall die Kommunikation in 
einem eigenen Thread.

Autor: Torsten Albrecht (torsten_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unbekannter schrieb:
> Es gibt überhaupt keinerlei Garantien wann und wie schnell Deine
>
>    Daten beim Empfänger ankommen.
>
>
>
>  - TCP ist ein sequentielles FIFO-Protokoll. Was als erstes gesendet
>
>    wird, bekommt der Empfänger als erstes
>
>
>
>  - Eine TCP-Verbindung besteht aus zwei "Kanälen". Die Sende-Richtung
>
>    und die Empfangs-Richtung. Beide Kanäle sind zeitlich in keiner
>
>    Weise miteinader korreliert.

aha wusste ich noch nicht!!!

Dennoch lasse ich nicht locker! Hier nochmal ein übertriebenes Beispiel:

Ein TCP Client (LabView) sendet 100 Setzbefehle (je 100 Zeichen) im 
Abstand von 2ms und anschließend eine Frage zum Server (MC + Wiznet IC) 
und wartet auf eine Antwort. Angenommen der Server benötigt 1 Sekunde 
zum Abarbeiten eines einzigen Befehls, nach Adam Ries kann der Server 
erst nach 101 Sekunden dem Client antworten. Der Client hängt aber schon 
nach 0,202 Sekunden in der "read-Schleife", da er schon mit dem Senden 
fertig ist. Ein Timeout für TCP read müsste demnach min. 101 Sekunden 
sein um die Antwort vom Server lesen zu können. Das ist doch Bockmist!!!
Deshalb würde ich gerne den TX-Buffer (winsock???window size??wie auch 
immer) des Clients auf beispielsweise 2048 Zeichen reduzieren. Somit 
würde die TCP-Send funktion des Clients viel früher ausgebremst und der 
Nachlauf des Servers verkürzt werden!!!

Autor: Torsten Albrecht (torsten_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Udo R. S. schrieb:
> Dann mach doch genau das:
>
> Der Client sendet einen Request und dann wartet er auf die Antwort. Das
>
> Warten kann man normalerweise mit einem Read mit timeout problemlos und
>
> ohne den Rechner zu belasten tun.

Kann ich machen, darf ich aber vom Auftraggeber her nicht! Deshalb suche 
ich nach Referenzen.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein TCP Client (LabView) sendet 100 Setzbefehle (je 100 Zeichen) im
> Abstand von 2ms und anschließend eine Frage zum Server (MC + Wiznet IC)
> und wartet auf eine Antwort. Angenommen der Server benötigt 1 Sekunde
> zum Abarbeiten eines einzigen Befehls

Sowas nennt man gemeinhin auch 'DOS'. Bring dem Client Manieren bei, 
alles andere ist Murks.

Autor: Udo R. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der yC 1 Sekunde zum abarbeiten eines Kommandos braucht, dann 
stören auch die 20ys für das Senden einer Quittung nach dem Abarbeiten 
an den Client nicht. Der Client soll halt dann warten bis der Befehl 
abgearbeitet ist bevor er den nächsten sendet.
Oder wie es der Vorposter gesagt hat:
"Bring dem Client Manieren bei, alles andere ist Murks."

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten Albrecht schrieb:
> Somit
> würde die TCP-Send funktion des Clients viel früher ausgebremst und der
> Nachlauf des Servers verkürzt werden!!!

Schieb' halt spätestens alle X Befehle immer eine "Frage" dazwischen, 
irgendwas wird es da doch wohl geben, was serverseitig keinen State 
verändert. Die Antwort kannst du dann ja einfach wegwerfen.

Andreas

Autor: Torsten Albrecht (torsten_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Udo R. S. schrieb:
> Wenn der yC 1 Sekunde zum abarbeiten eines Kommandos braucht, dann
>
> stören auch die 20ys für das Senden einer Quittung nach dem Abarbeiten
>
> an den Client nicht. Der Client soll halt dann warten bis der Befehl
>
> abgearbeitet ist bevor er den nächsten sendet.
>
> Oder wie es der Vorposter gesagt hat:
>
> "Bring dem Client Manieren bei, alles andere ist Murks."

Wie schon erwähnt soll keine eigene Lösung, wie beispielsweise ein ACK 
vom Server nach jedem Setzbefehl abwarten und dann den nächsten 
Setzbefehl senden, umgesetzt werden. Der Auftraggeber will einen 
Standard oder ein von renommiereten Firmen bewährtes Verfahren im 
Einsatz wissen! Daher die Quälerei!! Also Euch ist nichts bekannt???

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten Albrecht schrieb:
> Wie schon erwähnt soll keine eigene Lösung, wie beispielsweise ein ACK
> vom Server nach jedem Setzbefehl abwarten und dann den nächsten
> Setzbefehl senden, umgesetzt werden. Der Auftraggeber will einen
> Standard oder ein von renommiereten Firmen bewährtes Verfahren im
> Einsatz wissen! Daher die Quälerei!! Also Euch ist nichts bekannt???
Dann sage ich einfach mal HTTP... Oder WebDav... oder SOAP aber ob man 
sowas auf einem uC umsetzen will nur weil man sich zu fein ist das der 
Server z.B. nach jedem Befehl ein ACK zurücksendet. Das ist doch echt 
albern.

Autor: Udo R. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wüßte nicht daß es für ein einfaches Quittungsignal eine ISO oder 
auch DIN Norm gäbe. Das wäre fast so als würde es eine Norm zu geben wie 
man sich genau auf der Toilette zu erleichtern hat.

Autor: Udo R. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. schrieb:
> Dann sage ich einfach mal HTTP... Oder WebDav... oder SOAP aber ob man
> sowas auf einem uC umsetzen will nur weil man sich zu fein ist das der
> Server z.B. nach jedem Befehl ein ACK zurücksendet. Das ist doch echt
> albern

Haha,
ich hatte gerade geschrieben er solle es als Webservice implementieren, 
weil das -egal wie sinn odeer unsinnig das ist- derzeit Hip in den 
Führungsetagen ist, hab es aber wieder gelöscht weil ich dachte das wäre 
zu hart.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Udo R. S. schrieb:
> Führungsetagen ist, hab es aber wieder gelöscht weil ich dachte das wäre
> zu hart.
Manche lernen es nur auf die harte Tour ;P

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. schrieb:
> Udo R. S. schrieb:
>> Führungsetagen ist, hab es aber wieder gelöscht weil ich dachte das wäre
>> zu hart.
> Manche lernen es nur auf die harte Tour ;P



Ui. Aufpassen.
Von einem kannst du mit Sicherheit ausgehen:
Wenn du es nicht schaffst, der Führungsetage Blödsinn auszureden, bist 
nachher trotzdem du schuld.
Wenn es darum geht irgendwelchen hippen Unsinn durchzusetzen, sind die 
unglaublich hartnäckig. Und wahnsinnig gut darin, im Falle des Falles 
einen anderen Schuldigen zu finden.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Ui. Aufpassen.
> Von einem kannst du mit Sicherheit ausgehen:
> Wenn du es nicht schaffst, der Führungsetage Blödsinn auszureden, bist
> nachher trotzdem du schuld.
> Wenn es darum geht irgendwelchen hippen Unsinn durchzusetzen, sind die
> unglaublich hartnäckig. Und wahnsinnig gut darin, im Falle des Falles
> einen anderen Schuldigen zu finden.
Deshalb bin ich froh zur Zeit meine eigene Führungsetage zu sein ;)

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten Albrecht schrieb:
> Wie schon erwähnt soll keine eigene Lösung, wie beispielsweise ein ACK
> vom Server nach jedem Setzbefehl abwarten und dann den nächsten
> Setzbefehl senden, umgesetzt werden. Der Auftraggeber will einen
> Standard oder ein von renommiereten Firmen bewährtes Verfahren im
> Einsatz wissen!

Ein bewährtes Verfahren ist, ausnahmslos jedes Kommando auch zu 
quittieren, und sei es mit einem einfachen "OK". Hunderte 
(standardisierte) Netzwerkprotokolle machen das genau so, jedes Modem 
macht es bei AT-Befehlen so, selbst Menschen tun es (z.B. beim Funken).

Jetzt kann entweder bei jedem Kommando erst auf die Antwort gewartet 
werden, bevor das nächste gesendet wird (so wird es klassisch gemacht), 
oder aber es können weiter Kommandos gesendet werden, während noch auf 
die erste Antwort gewartet wird (das nennt sich dann auch "Pipelining"). 
Bei manchen Protokollen (IMAP z.B.) können die Kommandos sogar in einer 
anderen Reihenfolge beantwortet werden, als sie an den Server gesendet 
wurden (über Tags wird hier dafür gesorgt, dass die Antworten zu den 
Kommandos zugeordnet werden können).

Andreas

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist doch Bockmist!!!

Nö. Das ist die Realität. Die Welt ist nun mal asynchron und 
nebenläufig.


> [...] darf ich aber vom Auftraggeber her nicht! Deshalb suche
> ich nach Referenzen.

Sei mir nicht böse, aber da haben sich zwei gesucht und gefunden...


> Der Auftraggeber will einen Standard oder ein von renommiereten
> Firmen bewährtes Verfahren im Einsatz wissen!

Na, dann solltet ihr vielleicht bei diesen "renommierten Firmen" direkt 
anfragen. Die können euch vermutlich am besten helfen, oder auch 
nicht...


Polemik beiseite, es gibt viele denkbare Lösung für Dein "Problem": 
Look-ahead, Stop-and-Go, periodische Status-Updates, priorisierte und 
dedizierte Ports, etc.

Aber wahrscheinlich ist die genau Anwendung wieder so super-geheim und 
eine so dolle Erfindung, dass man ausser Nebelschwaden nicht viel mehr 
erfahren wird, was das Problem nun konkret ist.

Autor: Hans Hein (hanshein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ein TCP Client (LabView) sendet 100 Setzbefehle (je 100 Zeichen) im

= 10000Bytes, bei einer MTU von 1500 sind das 7 Netzwerkpakete,
die im Puffer (Windowsize) i.d.R. lokal im Netzwerkstack komplett
zwischengepuffert werden. Mal ge-tcpdump-ed/ge-wireshark-ed?

>Abstand von 2ms und anschließend eine Frage zum Server (MC + Wiznet IC)
>und wartet auf eine Antwort. Angenommen der Server benötigt 1 Sekunde
>zum Abarbeiten eines einzigen Befehls, nach Adam Ries kann der Server
>erst nach 101 Sekunden dem Client antworten.

Was spricht dagegen in Deiner Applikation die Arbeitspakete
in einen FIFO zu packen, die Steuerbefehle in einen anderen?
D.h. zu "muxen" und zu "demuxen". Prio hat die Steuerqueue...
Zwei Threads... Ja, das ist Arbeit!

> Der Client hängt aber schon
>nach 0,202 Sekunden in der "read-Schleife", da er schon mit dem Senden
>fertig ist.

Ui, tatsaechlich so lange? Der Client sendet wohl die 100 Satzbefehle
in 100 Paketen?

> Ein Timeout für TCP read müsste demnach min. 101 Sekunden
>sein um die Antwort vom Server lesen zu können. Das ist doch Bockmist!!!

d.h. nach diesen Anforderungen muss der Arbeitspaketbuffer muss >10k 
sein.

>Deshalb würde ich gerne den TX-Buffer (winsock???window size??wie auch
>immer) des Clients auf beispielsweise 2048 Zeichen reduzieren. Somit
>würde die TCP-Send funktion des Clients viel früher ausgebremst und der
>Nachlauf des Servers verkürzt werden!!!

Das geht nach meinem Wissen nur als globale Einstellung.
Deine Auftraggeber werden Dich lieben, wenn sie von dem Client
mal via Netzwerk ein Backup fahren wollen. Und was soll es bringen?
Holt der Client nun (automagisch) nach 50 Requests den Status ab??

Dein Problem hatte man uebrigens auch, als man das "Pipelining"
von HTTP-Requests von 1.0 aus in HTTP/1.1 eingebaut hat.
Man google nach "differences HTTP 1.0  1.1" und eines der ersten
Treffer ist
http://www2.research.att.com/~bala/papers/h0vh1.html
.... so zur Inspiration.

Also ein "kleiner" HTTP/1.1 Server waere nach den techn. Anforderungen
und Schlipsie-Hipp-Anforderungen schon passend....
Schaetzungsweise sollte man aber nicht mehr in Personentagen
rechnen, wenn man Pipelining sauber einzubauen gedenkt.


VG,
Hans

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.