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!
>- TCP Handshake endet am Wiznet-IC -> daher habe ich keine Möglichkeit > die Übertragung zu blockieren Ist auch besser so!
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.
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.
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.
>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
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.
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.
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
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!!
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.
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.
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!!!
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.
> 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.
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."
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
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???
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.
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.
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.
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
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.
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 ;)
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
> 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.
>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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.