#0 obligatoire avec winsock ?

**0x44-0x43-0x53-0x43** · 22/02/2012, 10h07

Bonjour,

Je désirais savoir si lorsque l'on utilise les API Winsock et que l'on effectue un send() si il est obligatoire de mettre un #0 a la fin de la chaîne a envoyer ?

Parce que j'ai remarqué dans certains cas, a la fin d'un texte envoyer (lors de la réception) il y a un caractère qui ne devrais pas être la.

Si j’insère le #0 il n’apparaît pas..

Il me semblait que Delphi géré automatiquement cela.

Merci d'avance

**ShaiLeTroll** · 22/02/2012, 10h19

send() selon la MSDN, on lui passe la taille du buffer donc le zéro n'a pas de conséquence à l'envoie
Heureusement, sinon on ne pourrait pas envoyer des record sérialisé si il y avait une gestion par zéro terminal (justement un bug du TCP\IP à l'époque de Windev 7.0)

Ensuite, pour la réception avec recv, c'est le même principe, on indique la taille du buffer mais surtout il renvoie le nombre d'octet réellement écrit !
C'est peut-être la ton erreur, tu utilise un StrPas ou un assimilé String\AnsiString implicite alors qu'il faut bien s'arrêter au nombre d'octet lu !

Evite le type string, préfere le type Windows.BYTE ou array of Byte, des buffers sans risque en XE2 !

surtout qu'en Delphi, le paramètre est un buffer non typé donc pas d'histoire de chaine à zéro terminal

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
function send(s: TSocket; var Buf; len, flags: Integer): Integer; stdcall;
function recv(s: TSocket; var Buf; len, flags: Integer): Integer; stdcall;

**0x44-0x43-0x53-0x43** · 22/02/2012, 10h22

Envoyé par ShaiLeTroll

send() selon la MSDN, on lui passe la taille du buffer donc le zéro n'a pas de conséquence à l'envoie
Heureusement, sinon on ne pourrait pas envoyer des record sérialisé si il y avait une gestion par zéro terminal (justement un bug du TCP\IP à l'époque de Windev 7.0)

Ensuite, pour la réception avec recv, c'est le même principe, on indique la taille du buffer mais surtout il renvoie le nombre d'octet réellement écrit !
C'est peut-être la ton erreur, tu utilise un StrPas ou un assimilé String\AnsiString implicite alors qu'il faut bien s'arrêter au nombre d'octet lu !

Evite le type string, préfere le type Windows.BYTE ou array of Byte, des buffers sans risque en XE2 !

surtout qu'en Delphi, le paramètre est un buffer non typé donc pas d'histoire de chaine à zéro terminal

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
function send(s: TSocket; var Buf; len, flags: Integer): Integer; stdcall;
function recv(s: TSocket; var Buf; len, flags: Integer): Integer; stdcall;

Ok je te remercie

**0x44-0x43-0x53-0x43** · 22/02/2012, 11h12

Encore une petite question cependant;

Lorsque j'ai reçu mon paquet dans un array of byte

C'est safe de le convertir dans un String sous XE ? (sachant que mon client est en ANSI (Delphi 2007) et le Server (XE2) donc Wide)

Sous XE buff = String, len = integer, arrBytes = Array Bytes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SetLength(buff, len);
MoveMemory(@buff[1],@arrBytes[0], len);

**ShaiLeTroll** · 22/02/2012, 14h35

N'ai je pas déjà répondu ?

Envoyé par ShaiLeTroll

Evite le type string, préfere le type Windows.BYTE ou array of Byte, des buffers sans risque en XE2 !

Utilise RawByteString à la limite, le mieux étant un TMemoryStream ou un PByte !

Tu sais pourtant que XE2 c'est en Unicode, prenons ton code, et voyons l'énorme erreur qu'il contient !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SetLength(buff, len);
MoveMemory(@buff[1],@arrBytes[0], len);

SetLength compte en caractère, tu vas donc créer une chaine de len caractères, ce qui donne len * 2 octets
Ensuite tu copie len octets par MoveMemory, donc au final, tu as la moitié de la chaine qui n'est pas rempli et une première moitié qui contiendra des caractères unicode problablement du chinois !

Oublie les String pour la manipulation d'octets, c'était une pratique possible en Delphi ANSI même si un peu dégueux mais maintenant c'est tout simplement dangereux !

**Andnotor** · 22/02/2012, 17h05

Si tu t'occupes du client et du serveur, il n'y a pas de problème à passer des chaînes. Il faut simplement bien spécifier une taille en octet !
Je suis justement en train de le tester sur des Pipes.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
const
  BufferSize = 4096;
 
procedure TNamedPipeDialogThread.Execute;
var
  Data  :string;
  Count :cardinal;
 
begin
  while not Terminated do
  begin
    SetLength(Data, BufferSize div SizeOf(Char));
 
    if ReadFile(Pipe, Data[1], BufferSize, Count, nil) then
    begin
      if Count > 0 then
      begin
        SetLength(Data, Count div SizeOf(Char));
 
        Synchronize(procedure
                    begin
                      if Assigned(Server.OnData) then
                        Server.OnData(Data);
                    end);
 
        if not WriteFile(Pipe, Data[1], Length(Data) *SizeOf(Char), Count, nil) then Break;
      end;
    end
    else Break;
  end;
 
  FlushFileBuffers(Pipe);
  DisconnectNamedPipe(Pipe);
  CloseHandle(Pipe);
end;