Immer nur 3 bytes aus Empfangsdaten weiterreichen..

[Rul]

Hi zusammen...

..ich komme im Moment nicht weiter und benötige einen Rat.

Wie kannich 3 Bytes über seriell einlesen?

Danke!

Rul

PS
Ich hab D6

[Uwe Raabe]

Deklariere dir einen Buffer für die verbleibenden Zeichen. Dann könnte die Routine so aussehen:

Delphi-Quellcode:

var
  Buffer: string;

procedure DataAvailable(const Data: string);
begin
  Buffer := Buffer + Data;
  while length(Buffer) > 2 do begin
    UDPCLIENT.SEND(Copy(Data, 1, 3));
    Delete(Data, 1, 3);
  end;
end;

[Rul]

Zitat von Uwe Raabe:

Deklariere dir einen Buffer für die verbleibenden Zeichen. Dann könnte die Routine so aussehen:

Delphi-Quellcode:

var
  Buffer: string;

procedure DataAvailable(const Data: string);
begin
  Buffer := Buffer + Data;
  while length(Buffer) > 2 do begin
    UDPCLIENT.SEND(Copy(Data, 1, 3));
    Delete(Data, 1, 3);
  end;
end;

Hallo Uwe,

danke ersteinmal :

ich erhalte eine Fehlermeldung:

"Konstantenobjekt kann nicht als Var-Parameter weitergegeben werden"

Irgendeine Idee?


Rul

Edit:
PS

eine zusätzliche Deklaration habe ich versucht aber da scheint die Application einzufrieren

Delphi-Quellcode:

var
  Buffer: string;
  neu : string;
procedure DataAvailable(const Data: string);
begin
neu := Data;
  Buffer := Buffer + neu;
  while length(Buffer) > 2 do begin
    UDPCLIENT.SEND(Copy(neu, 1, 3));
    Delete(neu, 1, 3);
  end;
end;

[Uwe Raabe]

Zitat von Rul:

ich erhalte eine Fehlermeldung:

"Konstantenobjekt kann nicht als Var-Parameter weitergegeben werden"

Irgendeine Idee?

Sicher - war irgendwie Unsinn:

Delphi-Quellcode:

procedure DataAvailable(const Data: string);
begin
  Buffer := Buffer + Data;
  while length(Buffer) > 2 do begin
    UDPCLIENT.SEND(Copy(Buffer , 1, 3));
    Delete(Buffer , 1, 3);
  end;
end;

[Rul]

[QUOTE=Uwe Raabe;1251905]

Zitat von Rul:

Delphi-Quellcode:

procedure DataAvailable(const Data: string);
begin
  Buffer := Buffer + Data;
  while length(Buffer) > 2 do begin
    UDPCLIENT.SEND(Copy(Buffer , 1, 3));
    Delete(Buffer , 1, 3);
  end;
end;

Das sieht gut aus!


Prinzip erkannt - mein Trivales Grundgerüst ist im Vergleich aber irgendwie schneller...

Es stockt noch ein Wenig - denke dass die DataAvailable prozedure sich mit den Erreignisen des UDP Client überschneidet,
kann ich da einen Thread oder Application.ProcessMessages einbringen?

Danke!!

Rul

[himitsu]

Wobei 3 Byte die Transportschicht doch etwas unterlasten.

Wenn der UDPCLIENT die Daten wirklich sofort versendet, wenn man sie an Send übergibt, dann vervielfacht der Overhead der Transportschichten die Daten doch um ein Vielfaches und das Übertragen dauert umso länger.

Ach ja, wenn die Daten unbedingt ankommen müssen, dann versende es besser via TCP.
Bei UDP kann es doch vorkommen, daß die Daten nicht ankommen und spurlos verschwinden.
Gut, dafür soll ja UDP schneller sein, da es eben keine Empfangskontrolle/Rückmeldung gibt.

Delphi-Quellcode:

procedure DataAvailable(const Data: string);
var
  i: Integer;
begin
  Buffer := Buffer + Data;
  i := (Length(Buffer) div 3) * 3;
  if i > 0 do begin
    UDPCLIENT.SEND(Copy(Buffer, 1, i));
    Delete(Buffer, 1, i);
  end;
end;

Da via UDP doch die Daten auch in anderen Reihenfolgen ankommen können, wenn überhaupt (wenn ich das richtig verstanden hab), dann kann man natürlich gern noch den Puffer aufteilen, so daß er maximal so groß ist, wie der kleineste Frame, in der Übertragung, so daß diese Bytes immer zusammen bleiben.

Delphi-Quellcode:

procedure DataAvailable(const Data: string);
var
  i: Integer;
begin
  Buffer := Buffer + Data;
  while Length(Buffer) > 2 do begin
    i := Min(Length(Buffer) div 3, 85) * 3;  // maximal 85 Pakete zusammen ... k.A. welche Größe Ideal wäre
    UDPCLIENT.SEND(Copy(Buffer, 1, i));
    // gibt es sowas wie ein UDPCLIENT.FLUSH?
    Delete(Buffer, 1, i);
  end;
end;

Man könnte natürlich auch auf den "Buffer" verzichten und die Daten direkt ans TCP weitergeben, ohne zusätzliches umkopieren und aufsplitten.

[Rul]

Zitat von himitsu:

Wobei 3 Byte die Transportschicht doch etwas unterlasten.

Wenn der UDPCLIENT die Daten wirklich sofort versendet, wenn man sie an Send übergibt, dann vervielfacht der Overhead der Transportschichten die Daten doch um ein Vielfaches und das Übertragen dauert umso länger.

Ach ja, wenn die Daten unbedingt ankommen müssen, dann versende es besser via TCP.
Bei UDP kann es doch vorkommen, daß die Daten nicht ankommen und spurlos verschwinden.
Gut, dafür soll ja UDP schneller sein, da es eben keine Empfangskontrolle/Rückmeldung gibt.

Delphi-Quellcode:

procedure DataAvailable(const Data: string);
var
  i: Integer;
begin
  Buffer := Buffer + Data;
  i := (Length(Buffer) div 3) * 3;
  if i > 0 do begin
    UDPCLIENT.SEND(Copy(Buffer, 1, i));
    Delete(Buffer, 1, i);
  end;
end;

Da via UDP doch die Daten auch in anderen Reihenfolgen ankommen können, wenn überhaupt (wenn ich das richtig verstanden hab), dann kann man natürlich gern noch den Puffer aufteilen, so daß er maximal so groß ist, wie der kleineste Frame, in der Übertragung, so daß diese Bytes immer zusammen bleiben.

Delphi-Quellcode:

procedure DataAvailable(const Data: string);
var
  i: Integer;
begin
  Buffer := Buffer + Data;
  while Length(Buffer) > 2 do begin
    i := Min(Length(Buffer) div 3, 85) * 3;  // maximal 85 Pakete zusammen ... k.A. welche Größe Ideal wäre
    UDPCLIENT.SEND(Copy(Buffer, 1, i));
    // gibt es sowas wie ein UDPCLIENT.FLUSH?
    Delete(Buffer, 1, i);
  end;
end;

Man könnte natürlich auch auf den "Buffer" verzichten und die Daten direkt ans TCP weitergeben, ohne zusätzliches umkopieren und aufsplitten.

Hallo Himitsu,

ich werde das im Anschluss gleich einmal versuchen.

.."Da via UDP doch die Daten auch in anderen Reihenfolgen ankommen können,.."

Das ist eine sehr interessantze Info -
Da muss ich meine Strecke nochmal überdenken... vieleicht habe ich einen Denkfehler in meinem Aufbau...

Ich muss leider UDP nehmen -

Frage:
Kann man die "Reihenfolge der UDP Daten" kontrollieren und richtig stellen im UDP Verfahren oder ist nur TCP ordentlich?

Das ganze passiert auf dem Endrechner.

Deine Beispiele werde ich versuchen und berichten, danke!!!!

LG

Rul

[Uwe Raabe]

Zitat von Rul:

Prinzip erkannt - mein Trivales Grundgerüst ist im Vergleich aber irgendwie schneller...

Es stockt noch ein Wenig - denke dass die DataAvailable prozedure sich mit den Erreignisen des UDP Client überschneidet,
kann ich da einen Thread oder Application.ProcessMessages einbringen?

Dazu kann ich ohne Kenntnis deines Codes nicht viel sagen.

Ich weiß auch nicht, ob du erfahren genug bist, einen Thread korrekt zu implementieren. Dein ursprünglicher Code läßt das eher zweifelhaft erscheinen. Von ProcessMessages rate ich in jedem Fall ab - das macht es definitiv nicht schneller sondern nur schwieriger die Fehler zu finden.

Als erstes müsste man wohl analysieren, wo die kritischen Stellen wirklich liegen.

[Rul]

Zitat von Uwe Raabe:

Ich weiß auch nicht, ob du erfahren genug bist, einen Thread korrekt zu implementieren. Dein ursprünglicher Code läßt das eher zweifelhaft erscheinen. Von ProcessMessages rate ich in jedem Fall ab - das macht es definitiv nicht schneller sondern nur schwieriger die Fehler zu finden.

Hallo Uwe,
also Threads in diesem Sinne wäre jetzt mein erster Schritt dahin -



das mal mit Hintergedanke und bewusst einsetzen zu wollen wäre jetzt das erste Mal

Dabei darf natürlich der Datenfluss der weiter reingeht nicht verlorengehen,
deshalb der primitive Aufbau der "Stringliste" zum Sequentiellen Abarbeiten...weil ich darin noch keine Erfahrung habe.

btw:
Eine andere Frage beschäftigt mich noch, ist es denn nicht möglich einen "0" Bytes String in einem Edit "festzuhalten"?

danke!

Rul

[himitsu]

Ein "TEdit" kann nunmal keine #0 darstellen und auch einige Steuerzeichen sollte man beachten.
Die Schnittstelle arbeitet via PChar und dort dient die #0 als Ende-Markierung.

Bei der Anzeige muß man solche Zeichen vorher irgendwie "konvertieren", in etwas, was das Edit darstellen kann.

Zitat:

UDP ist ein verbindungsloses, nicht-zuverlässiges und ungesichertes wie auch ungeschütztes Übertragungsprotokoll. Das bedeutet, es gibt keine Garantie, dass ein einmal gesendetes Paket auch ankommt, dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden, oder dass ein Paket nur einmal beim Empfänger eintrifft. Es gibt auch keine Gewähr dafür, dass die Daten unverfälscht oder unzugänglich für Dritte beim Empfänger eintreffen. Eine Anwendung, die UDP nutzt, muss daher gegenüber verlorengegangenen und unsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmaßnahmen und ggfs. auch Sicherungsmaßnahmen vorsehen. Ein Datenschutz ist bei dieser offenen Kommunikation nicht möglich.

Quelle: http://de.wikipedia.org/wiki/User_Datagram_Protocol

Wie geagt.

UDP hat keinerlei Rückmeldungen.

Wenn ein Paket schneller übertragen wird, als das vorherrige Paket, dann kann es passieren, daß es vorher beim Ziel ankommt und da auch früher verarbeitet wird.
Genauso kann es sein, daß es auch einfach verloren geht, wenn es irgendwo hängen bleibt.

Beim TCP wurde dagegen noch etwas mehr eingebaut.
Der Empfänger prüft die eintreffenden Pakete, sortiert Diese und meldet auch deren Eintreffen beim Sender. Wenn der Sender keine Meldung bekommt (innerhalb eines Timeouts), dann sendet er das/die fehlende(n) Paket(e) nochmals, so daß immer alle Pakete garantiert und in der richtigen Reihenfolge eintreffen.

UDP macht nichts davon. Dafür ist die Verbindung halt schneller, da jegliche Rückmeldung und Paketverwaltung fehlt.


Man kann bei UDP natürlich auch die Reihenfolge und den Empfang sicherstellen, aber das muuß man dann selber implementieren.
In den Paketen z.B. eine vortlaufende ID einfügen, um die Reihenfolge zu prüfen.
Oder jeweils die Kennung des nächsten Pakets im vorherigen mitgeben.
Außerdem beim Fehlen das fehlende Paket beim Absender erneut anfragen und neu zuschicken lassen.
Das muß natürlich dann im Sender und im Empfänger implementiert werden.

Oder man macht es wir beim Seriellen Port, mit dem Acknowledgement-Flag.
- Paket senden
- auf das Acknowledge-Signal warten
- wenn es nich kam, dann nochmal senden
- jetzt erst das nächste Paket senden (also von vorne wiederholen)
(TCP hat das etwas optimiert, indem es nicht bei jedem einzelnen Paket auf die Bestätigung wartet, bevor es das nächste Paket sendet)