Indy10 Kommunikation über UDP mit 8 Bit Codierung

[AJ_Oldendorf]

Hallo erstmal :-)

UDP Kommunikation mit Indy Komponenten

BDS 2006 und Indy 10 = OK
RAD 2009 und Indy 10 = NICHT OK

Ich benutze den TIdUDPClient um Daten über UDP zu senden.

1. TIdUDPClient

Funktionsaufruf:

procedure Send(const AData: string); overload;

2. TIdUDPClient abgeleitet von TIdUDPBase

Funktionsaufruf:

procedure Send(const AHost: string; const APort: TIdPort; const AData: string);

Diese Funktion ruft widerrum folgende auf:

SendBuffer(AHost, APort, ToBytes(AData));



Hier liegt der Knausus Knaktus...

ToBytes(AData) wird aufgerufen mit einem Standardparameter als const

function ToBytes(const AValue: string; const AEncoding: TIdEncoding = en7Bit): TIdBytes; overload;
{$IFDEF USEINLINE}inline;{$ENDIF}
begin
Result := ToBytes(AValue, -1, 1, AEncoding);
end;


Warum wird hier überall mit der 7 Bit Codierung gearbeitet?
Man hat von außen keine Chance dies zu ändern...
Ich brauche aber unbedingt das 8 Bit Format. Es gibt ja auch den Parameter en8Bit aber ich kann
ja in den Indy's nichts ändern.
Wie bekomme ich es hin, dass meine ganze Kommunikation (über UDP) mit en8Bit arbeitet?
Es gibt in den Indy's keine Möglichkeit einen globalen Schalter zu setzen, dass mit 8 Bit
Verschlüssung alles gemacht werden soll.
Die Kommunikation über UDP mit BDS 2006 und den darin mitgelieferten Indy10 funktioniert.
Nur in RAD2009 funktioniert es nicht.

Habt ihr eine Lösung oder Idee hierfür?
Meine Software auf 7 Bit Codierung umzustellen kommt dabei wirklich nicht in Frage...

Viele Grüße im voraus,
Alex

[Assertor]

Hi,

Zitat:

Zitat von AJ_Oldendorf

1. TIdUDPClient

Funktionsaufruf:

procedure Send(const AData: string); overload;

Indy Version updaten, wir haben die Encoding Wrapper bereits erweitert (ca. März 2009). Der Aufruf lautet nun:

Delphi-Quellcode:

TIdUDPClient.Send(const AData: string; AEncoding: TIdTextEncoding = nil); overload;

und

TIdUDPBase.Send(const AHost: string; const APort: TIdPort; const AData: string;
  AEncoding: TIdTextEncoding = nil);

Alternativ: Eigene Klasse ableiten und Send() mit reintroduce/overload selbst korrigieren. Gleiches für UDPBase.

Zitat:

Zitat von AJ_Oldendorf

Warum wird hier überall mit der 7 Bit Codierung gearbeitet?

Weil die meisten Internet Standards für die Protokolle (RFCs) dies fordern. Es gibt einige Erweiterungen, z.B. MIME Extensions, 8BITMIME bei SMTP etc.pp. - aber die Protokolle sind eben häufig 7bit textbasiert. Erst Erweiterungen und Neufassungen erlauben manchen Protokollen andere Encodings. Wo möglich und geboten, entscheiden die Komponenten selbst über das sinnvollste und konforme Encoding.

In Deinem Fall fehlte aber tatsächlich die Durchreichung des Encodings. Mit der aktuellen Version ist dies auch wieder implementiert.

Gruß Assertor

[AJ_Oldendorf]

Ich habe mir die aktuellen Indy's von fulgan (glaube ich) gezogen, Stand vorgestern Abend, da war der Source in diesem Bereich noch der gleiche...
Wo bekomme ich denn die Version die du meinst?
Danke aber für deine Hilfe.
Viele Grüße
Alex

[omata]

Zitat:

Zitat von Assertor

Alternativ: Eigene Klasse ableiten und Send() mit reintroduce/overload selbst korrigieren.

reintroduce/override = korrigieren
overload = erweitern

[Assertor]

Zitat:

Zitat von omata

Zitat:

Zitat von Assertor

Alternativ: Eigene Klasse ableiten und Send() mit reintroduce/overload selbst korrigieren.

reintroduce/override = korrigieren
overload = erweitern

Und das um 23:34 als einziges zu diesem Thread... :roll:

Ich fass mal das wesentlich für Dich zusammen:

Zitat:

Zitat von Assertor

Alternativ: Eigene Klasse ableiten und [...] selbst korrigieren.

Im Sinne von "den Fehler selbst korrigieren". Das läßt sich leider im Sinne der deutschen Sprache nicht überladen oder erweitern, sondern nur korrigieren...

Eine Erklärung bedürfen doch reintroduce/override/overload eigentlich nicht, sind sie ja sprachlich so eindeutig wie begin und end. Weiteres geht in Kopie an den Zwiebelfisch :mrgreen:

Gruß Assertor

[AJ_Oldendorf]

@Assertor: Wo bekomme ich denn die von dir erwähnte Version der Indy's her?

Viele Grüße
Alex

[Assertor]

Hi Alex,

Zitat:

Zitat von AJ_Oldendorf

@Assertor: Wo bekomme ich denn die von dir erwähnte Version der Indy's her?

Vom Fulgan Mirror:
ftp://ftp.fulgan.com/ZIP/IndyTiburon.zip

Zitat:

Zitat von AJ_Oldendorf

Ich habe mir die aktuellen Indy's von fulgan (glaube ich) gezogen, Stand vorgestern Abend, da war der Source in diesem Bereich noch der gleiche...
Wo bekomme ich denn die Version die du meinst?
Danke aber für deine Hilfe.

Hattest Du denn die aktuelle IndyTiburon.zip geladen?

Gruß Assertor

[AJ_Oldendorf]

Hallo Assertor,
ich hatte anscheind irgendwie eine andere Version erwischt...
Jetzt sieht man, dass man bei der Funktion .Send ein Encoding Format angeben kann.
Leider funktioniert die 8bit Übertragung nicht.

Ich hänge dir mal zwei Beispielprojekte an.

Die Testanwendungen zum Senden und Empfangen mit UDP.
Die Datei UDPSendSequenz-BDS2006.zip enthält Quelltext und Anwendung zum Senden einer fortlaufenden wort-breiten Sequenznummer an die angegebene Ip-Adresse.
Compliert mit BDS 2006. Das klappt auch!

Die Datei UDPSendReceive-BDS2009.zip enthält Quelltext und die Anwendung für Senden und Empfangen unter Verwendung der neuen Indys (die du mir genannt hast).
Das Ding kann Senden (fehlerhaft) und Empfangen (da kommen die richtigen Werte, die man mit der BDS 2006 Anwendung abgschickt hat).

Zwischen 128 und 159 werden die Sequenzen verfälscht..
Schuld daran ist das Verwenden von Codepages. Wir müssen hier aber 8bit binär (1:1 !) übertragen.

IdGlobal; Zeile 2280 ff.
// RLebeau: TODO - implement a custom 8-bit encoding class?
//
// We need a class that converts UFT-16 codeunits in the $00-$FF range
// to/from their numeric values as-is. Was previously using "Windows-1252"
// (codepage 1252) for that, which does so for most codeunits, however
// codeunits $80-$9F in Windows-1252 map to different codepoints in Unicode,
// which we don't want. "ISO 8859-1" (codepage 28591), on the other hand,
// treats codeunits $00-$FF as-is, and seems to be just as widely supported
// as codepage 1252 on most systems, so we'll use that for now...

Delphi-Quellcode:

{$IFDEF DOTNET}
function Indy8BitEncoding: TIdTextEncoding;
{$IFDEF USEINLINE}inline;{$ENDIF}
begin
 Result := TIdTextEncoding.GetEncoding(28591);
end;
{$ELSE}
 {$IFDEF USE_ICONV}
function Indy8BitEncoding(const AOwnedByIndy: Boolean = True): TIdTextEncoding;
var
 LEncoding: TIdTextEncoding;
begin
 if not AOwnedByIndy then begin
   LEncoding := TIdTextEncoding.GetEncoding('ISO-8859-1');
 end else
 begin
   if GId8BitEncoding = nil then begin
     LEncoding := TIdTextEncoding.GetEncoding('ISO-8859-1');
     if InterlockedCompareExchangePtr(Pointer(GId8BitEncoding), LEncoding, nil) <> nil then begin
       LEncoding.Free;
     end;
   end;
   LEncoding := GId8BitEncoding;
 end;
 Result := LEncoding;
end;

Ich hoffe, du verstehst unser Problem und kannst mir hierzu noch weiterhelfen.
Wie oben geschrieben brauchen wir unbedingt eine 8bit (1:1) Übertragung.

Viele Grüße
Alex

[Assertor]

Hi,

Ich werd mir das Beispiel mal ansehen...

Zitat:

Zitat von AJ_Oldendorf

Wie oben geschrieben brauchen wir unbedingt eine 8bit (1:1) Übertragung.

1) Dann ist aber das Senden eines Strings eine unglückliche Wahl. Bei der Verwendung von (Unicode-)Strings in D2009 schlägt an vielen Stellen ja auch die Compiler Magic zu und es werden auch teilweise automatische Umwandlungen vorgenommen.

Es besteht doch die Möglichkeit Binärdaten zu übertragen (.SendBuffer) - warum nutzt ihr dies nicht?

2) In D2009 wird Indy8BitEncoding zumindest dort nicht benötigt, senden geht über die D2009 TEncoding Klassen, z.B.

Delphi-Quellcode:

IdUDPServer1.Send('test', 20, 'test', TEncoding.Unicode);
// oder
IdUDPServer1.Send('test', 20, 'test', TEncoding.UTF8);

Gruß Assertor

[AJ_Oldendorf]

Danke für die schnelle Antwort.
Mit SendBuffer haben wir es auch schon probiert und hatten das gleiche Problem mit der Übertragung.
Wäre super, wenn du dir das Beispiel mal anguckst und mir Bescheid gibst.
Dein zweiten Punkt mit dem Senden gucke ich mir nachher mal an.
Danke im voraus,
Alex