Entwickler-Ecke
Internet / Netzwerk - Socket kommunikation D2010
thepaine91 - Mi 18.05.11 12:25
Titel: Socket kommunikation D2010
Hallo ich habe mein D6 Projekt auf D2010 umgestellt und das ganze funktioniert nur halb.
Ich glaube das Problem ist folgendes:
Delphi-Quelltext
1:
2:
3:
4:
| function TCustomWinSocket.SendText(const s: String): Integer;
begin
Result := SendBuf(Pointer(S)^, Length(S) * SizeOf(Char));
end; |
Da
Martok vorhin erwähnt hat das ein Unicodezeichen nicht immer 2 Byte belegt stellt sich mir die Frage ob man das überhaupt mit einem Widechar wie oben berechnen kann.
Fakt ist die Daten kommen auf der anderen Seite an allerdings nur fehlerhaft.
Narses - Mi 18.05.11 13:15
Moin!
thepaine91 hat folgendes geschrieben  : |
| Hallo ich habe mein D6 Projekt auf D2010 umgestellt |
In diesem Fall solltest du alle Strings, die über´s Netz gehen, als
AnsiString deklarieren und
String-Parameter in utf8 konvertieren. Das ist IMHO der Beste Ansatz für so eine Umstellung. :idea:
| thepaine91 hat folgendes geschrieben : |
Ich glaube das Problem ist folgendes:
Delphi-Quelltext 1:
2:
3:
4:
| function TCustomWinSocket.SendText(const s: String): Integer;
begin
Result := SendBuf(Pointer(S)^, Length(S) * SizeOf(Char));
end; | |
Wo hast du das Code-Stück her? Grundsätzlich nicht "schön", aber unter D2010 IMHO OK.
Das bei Strings mit einer Datenmenge >8KB dieser String bei .ReceiveText()
nicht wieder "an einem Stück raus" kommt, ist dir aber bekannt?
cu
Narses
thepaine91 - Mi 18.05.11 13:34
| Narses hat folgendes geschrieben: |
In diesem Fall solltest du alle Strings, die über´s Netz gehen, als AnsiString deklarieren und String-Parameter in utf8 konvertieren. Das ist IMHO der Beste Ansatz für so eine Umstellung. :idea:
|
Okay das ist schon mal ein Ansatz (so sah es auch vor meiner Änderung aus... -.-*) :oops: .
| Narses hat folgendes geschrieben: |
Wo hast du das Code-Stück her? Grundsätzlich nicht "schön", aber unter D2010 IMHO OK.
|
Das Codestück ist aus der Unit ScktComp aus D2010, hab mir das abgeleitet und umgeschrieben.
| Narses hat folgendes geschrieben: |
Das bei Strings mit einer Datenmenge >8KB dieser String bei .ReceiveText() nicht wieder "an einem Stück raus" kommt, ist dir aber bekannt? |
Ja ist mir bekannt die Basis des Programms kommt auch aus deinem Tutorial. ;)
EDIT:
Ach so sieht übrigens ReceiveText aus:
Delphi-Quelltext
1:
2:
3:
4:
5:
| function TCustomWinSocket.ReceiveText: String;
begin
SetLength(Result, ReceiveBuf(Pointer(nil)^, -1));
SetLength(Result, ReceiveBuf(Pointer(Result)^, Length(Result)));
end; |
(Daran habe ich nichts verändert.)
Narses - Mi 18.05.11 15:26
Moin!
| thepaine91 hat folgendes geschrieben : |
Ach so sieht übrigens ReceiveText aus:
Delphi-Quelltext 1:
| function TCustomWinSocket.ReceiveText: String; | (Daran habe ich nichts verändert.) |
Da steht ernsthaft im Original String?!? :shock: Da muss unbedingt ein AnsiString hin, der "Fehler" (stammt aus D2009) sollte doch eigentlich in D2010 wieder raus sein... :gruebel: (die ScktComp-Sockets sind auf AnsiString ausgelegt und kriegen auch nix anderes auf die Kette; das hat nix mit der WSA zu tun, sondern mit dem Design der Kompos, ist halt so)
cu
Narses
jaenicke - Do 19.05.11 05:40
In Delphi XE steht da wieder AnsiString.
Allerdings funktioniert es auch problemlos mit Unicodezeichen... ja, wenn man es denn richtig macht. Der gepostete Quelltext von ReceiveText ist schlicht falsch...
| thepaine91 hat folgendes geschrieben : |
Delphi-Quelltext 1:
2:
3:
4:
5:
| function TCustomWinSocket.ReceiveText: String;
begin
SetLength(Result, ReceiveBuf(Pointer(nil)^, -1)); SetLength(Result, ReceiveBuf(Pointer(Result)^, Length(Result)));
end; | |
Wenn man das richtig macht, funktioniert es zumindest bei XE absolut problemlos mit Unicode, ich habe diverse Tests gemacht. Hier mal ein Fix:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
| type
TUnicodeCustomWinSocketHelper = class helper for TCustomWinSocket
public
function SendUnicodeText(const Value: String): Integer;
function ReceiveUnicodeText: String;
end;
function TUnicodeCustomWinSocketHelper.ReceiveUnicodeText: String;
begin
SetLength(Result, ReceiveBuf(Pointer(nil)^, -1) div SizeOf(Char));
SetLength(Result, ReceiveBuf(Pointer(Result)^, Length(Result) * SizeOf(Char)) div SizeOf(Char));
end;
function TUnicodeCustomWinSocketHelper.SendUnicodeText(const Value: String): Integer;
begin
Result := SendBuf(Pointer(Value)^, Length(Value) * SizeOf(Char));
end; |
Was in dem Originalquelltext nämlich nicht beachtet wird, ist dass auch beim Empfang ein Zeichen nun einmal nicht ein Byte hat.
Statt das also wieder auf AnsiString zu setzen, hätten sie es besser dort richtig korrigiert...
Mit SendBuf und ReceiveBuf funktioniert es hier jedenfalls problemlos. Ich habe gerade diverse Unicodetexte geschickt, es gab keinerlei Probleme:
thepaine91 - Do 19.05.11 07:55
Danke für eure Hilfe, @Jaenicke dann werde ich das mal abändern. Finde es auch schöner gleich Unicode zu verschicken als x mal zu konvertieren.
Edit:
So es funktioniert nun Einwandfrei :) :D :dance2: :dunce: :nut:
Aber Kopieren kann ja jeder daher versuche ich die Änderung zu verstehen.
Also so verstehe ich es:
Ansistring der Länge 3 = 3 Byte;
Widestring der Länge 3 = 6 Byte;
Da ReceiveBuf die Anzahl der tatsächlich gelesenen Bytes zurück gibt, wird Result dann auf 6 anstatt auf 3 gesetzt und das hast du mit div SizeOf(Char) geändert. Richtig?
---
Moderiert von Narses: Beiträge zusammengefasst---
Hoffe das gilt nicht als Schiebung? (Da es ja ein neuer Abschnitt zum Thema ist) Falls doch bitte ich um Entschuldigung.
Ich steht nun vor dem Problem die gesamte Kommunikation zwischen den beteiligten zu verschlüsseln. Das Verschlüsseln ist dabei nicht das Problem sondern das die Daten nicht an einem Stück beim empfänger ankommen müssen. Entsprechend funktioniert das dann natürlich nicht.
(TCP)
Meine einzige Idee ist die verschlüsselten Daten in gesondertes Tags ein zu betten. (Sowas wie [Encoded] ^^)
Aber toll finde ich das jetzt auch nicht...
Lieber wäre mir das ich die Pakete selbst verwalte und diese verschlüssel. Da dies aber von Windoof verwaltet wird sollte das schwierig werden.....
Hat also jemand eine bessere Idee?
Narses - Do 19.05.11 11:24
Moin!
| thepaine91 hat folgendes geschrieben : |
Ich steht nun vor dem Problem die gesamte Kommunikation zwischen den beteiligten zu verschlüsseln. Das Verschlüsseln ist dabei nicht das Problem sondern das die Daten nicht an einem Stück beim empfänger ankommen müssen. Entsprechend funktioniert das dann natürlich nicht.
(TCP) |
Also wie jetzt, du hast eine TCP-Verbindung, aber die Daten kommen nicht korrekt an?! :gruebel:
| thepaine91 hat folgendes geschrieben : |
| Hat also jemand eine bessere Idee? |
Die Verschlüsselung auf Transport-Layer-Ebene umsetzen,
hier habe ich sowas schonmal gemacht [
http://www.delphi-forum.de/viewtopic.php?p=450581#450581]. (evtl. auch mal ein paar Beiträge vorher/nachher lesen) :idea: ;)
cu
Narses
thepaine91 - Do 19.05.11 12:10
| Narses hat folgendes geschrieben : |
| thepaine91 hat folgendes geschrieben : | | Ich steht nun vor dem Problem die gesamte Kommunikation zwischen den beteiligten zu verschlüsseln. Das Verschlüsseln ist dabei nicht das Problem sondern das die Daten nicht an einem Stück beim empfänger ankommen müssen. Entsprechend funktioniert das dann natürlich nicht. |
Also wie jetzt, du hast eine TCP-Verbindung, aber die Daten kommen nicht korrekt an?! :gruebel: |
Nein ich wollte damit sagen das ich es mit der Socketkomponente nicht in der Hand hab wie die Daten gestückelt werden. Und somit meine Daten nicht komplett verschlüsseln kann.
Genau so etwas habe ich gesucht wusste nur nicht wie ich das angehen soll.
Danke sollte mir erst mal als Stoff genügen.
thepaine91 - Fr 20.05.11 08:43
Da ich atm nicht so viel Zeit habe musste ich das ganze schnell Programmieren.
Naja daher hab ich jetzt einfach eine 2. Protokollebene, die nur auf Vollständigkeit eines Datensatzes prüft, eingefügt. Sobald der Datensatz Vollständig ist wird er Decoded und Fertig. Encoden tut der Socket und Decoden der Parser des Protokolls.
Nicht schön aber ging schnell und funktioniert. ^^
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!