AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Immer nur 3 bytes aus Empfangsdaten weiterreichen..

Immer nur 3 bytes aus Empfangsdaten weiterreichen..

Ein Thema von Rul · begonnen am 13. Mär 2014 · letzter Beitrag vom 15. Mär 2014
Thema geschlossen
Seite 1 von 2  1 2   
Rul

Registriert seit: 13. Mär 2014
10 Beiträge
 
#1

Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 19:36
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

Geändert von Rul (14. Mär 2014 um 12:36 Uhr)
 
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
7.347 Beiträge
 
Delphi 10.3 Rio
 
#2

AW: Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 19:45
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;
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
 
Rul

Registriert seit: 13. Mär 2014
10 Beiträge
 
#3

AW: Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 20:01
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;

Geändert von Rul (13. Mär 2014 um 20:07 Uhr)
 
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
7.347 Beiträge
 
Delphi 10.3 Rio
 
#4

AW: Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 20:05
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;
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
 
Rul

Registriert seit: 13. Mär 2014
10 Beiträge
 
#5

AW: Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 20:13
[QUOTE=Uwe Raabe;1251905]
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
 
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
35.212 Beiträge
 
Delphi 10.3 Rio
 
#6

AW: Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 20:18
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (13. Mär 2014 um 20:23 Uhr)
 
Rul

Registriert seit: 13. Mär 2014
10 Beiträge
 
#7

AW: Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 20:37
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

Geändert von Rul (14. Mär 2014 um 12:38 Uhr)
 
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
7.347 Beiträge
 
Delphi 10.3 Rio
 
#8

AW: Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 20:44
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
 
Rul

Registriert seit: 13. Mär 2014
10 Beiträge
 
#9

AW: Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 21:00

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

Geändert von Rul (14. Mär 2014 um 12:39 Uhr)
 
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
35.212 Beiträge
 
Delphi 10.3 Rio
 
#10

AW: Immer nur 3 bytes aus Empfangsdaten weiterreichen..

  Alt 13. Mär 2014, 21:10
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)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (13. Mär 2014 um 21:23 Uhr)
 
Thema geschlossen
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:29 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf