AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke Delphi Spielwiese - SocketTest
Thema durchsuchen
Ansicht
Themen-Optionen

Spielwiese - SocketTest

Ein Thema von stahli · begonnen am 7. Okt 2016 · letzter Beitrag vom 24. Mär 2017
Antwort Antwort
Seite 4 von 4   « Erste     234   
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#31

AW: Spielwiese - SocketTest

  Alt 23. Dez 2016, 14:38
Meine Anwendung ist nicht blockierend.
Ah, okay, das ist dann wohl neu.

Also ich muss vorweg sagen, ich habe mit TClientSocket/TServerSocket nie gearbeitet, wohl aber mit der dahinterliegenden BSD-Socket bzw. WinSock-API. Dort ist es so, dass die Funktion recv() einen Wert zurückliefert, der angibt, wieviele Bytes tatsächlich gelesen wurde (oder -1 falls keine Bytes gelesen werden konnten oder im Falle eines Fehlers). Ein Rückgabewert von 0 bedeutet, dass die Verbindung geschlossen wurde. Das könnte hier der Fall sein. Das kannst du aber nur herausfinden, indem du tatsächlich ein recv ausführst, ReceiveLength ist irreführend.

Wenn du deinen Code nicht überall ändern willst, kannst du einfach 1 Byte lesen und als Flag MSG_PEEK übergeben. So wird das Byte nicht "konsumiert" und der restliche Programmablauf bleibt unbeeinflusst.
Delphi-Quellcode:
var
  Dummy: Byte;
begin
  if Socket.ReceiveBuf(Dummy, 1, MSG_PEEK) = 0 then
    // Verbindung geschlossen;
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#32

AW: Spielwiese - SocketTest

  Alt 23. Dez 2016, 14:45
Dort ist es so, dass die Funktion recv() einen Wert zurückliefert, der angibt, wieviele Bytes tatsächlich gelesen wurde (oder -1 falls keine Bytes gelesen werden konnten oder im Falle eines Fehlers). Ein Rückgabewert von 0 bedeutet, dass die Verbindung geschlossen wurde. Das könnte hier der Fall sein. Das kannst du aber nur herausfinden, indem du tatsächlich ein recv ausführst, ReceiveLength ist irreführend.
Das ist bei den (dummen ) non-blocking Sockets leider auch wieder mal komplizierter:
Zitat von MSDN recv():
If no incoming data is available at the socket, the recv call blocks and waits for data to arrive according to the blocking rules defined for WSARecv with the MSG_PARTIAL flag not set unless the socket is nonblocking. In this case, a value of SOCKET_ERROR is returned with the error code set to WSAEWOULDBLOCK. The select, WSAAsyncSelect, or WSAEventSelect functions can be used to determine when more data arrives.
@stahli:
Deine Send-Routine enthält auf jeden Fall das von mir beschriebene Problem, dass MSDN-Library durchsuchensend deine Daten bei non-blocking Sockets leider NICHT garantiert komplett verschickt:
Zitat von MSDN send():
If no buffer space is available within the transport system to hold the data to be transmitted, send will block unless the socket has been placed in nonblocking mode. On nonblocking stream oriented sockets, the number of bytes written can be between 1 and the requested length, depending on buffer availability on both the client and server computers. The select, WSAAsyncSelect or WSAEventSelect functions can be used to determine when it is possible to send more data.
Achso: Den TCP Stack direkt buffern zu lassen - wie du es momentan machst -, ist meiner Meinung nach keine gute Idee. Die Buffergröße hängt von verschiedenen Parametern ab und kann sich von System zu System stark unterscheiden. Wenn du dann versuchst eine Nachricht zu schicken, die nicht komplett in den Buffer passt, wird deine Verbindung dauerhaft blockiert sein, da du in diesem Falle ja niemals Daten ausliest (also auch keinen neuen Platz im Receive-Buffer schaffst).
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)

Geändert von Zacherl (23. Dez 2016 um 14:51 Uhr)
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#33

AW: Spielwiese - SocketTest

  Alt 23. Dez 2016, 15:02
Das ist bei den (dummen ) non-blocking Sockets leider auch wieder mal komplizierter:
Zitat von MSDN recv():
If no incoming data is available at the socket, the recv call blocks and waits for data to arrive according to the blocking rules defined for WSARecv with the MSG_PARTIAL flag not set unless the socket is nonblocking. In this case, a value of SOCKET_ERROR is returned with the error code set to WSAEWOULDBLOCK. The select, WSAAsyncSelect, or WSAEventSelect functions can be used to determine when more data arrives.
Es ist schon so, wie ich es geschrieben habe. Die Dokumentation liest sich nur leider manchmal etwas verwirrend.

Ich versuche es noch mal in Tabellenform:
Code:
                               | Verbindung besteht | Verbindung geschlossen
Lesbare Bytes vorhanden        | > 0                | --
Keine lesbaren Bytes vorhanden | -1                 | 0
Fehler                         | -1                 | -1

(Wie zur Hölle verwendet man den [TABLE]-BBCode? )
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#34

AW: Spielwiese - SocketTest

  Alt 23. Dez 2016, 15:07
Meine Anwendung ist nicht blockierend.
Ah, okay, das ist dann wohl neu.
Hier im Thread und Testprojekt ging es immer um non blocking.

Mein echtes Projekt hatte Indy genutzt, also blocking.
Das stelle ich derzeit entsprechend um.


@stahli:
Deine Send-Routine enthält auf jeden Fall das von mir beschriebene Problem, dass MSDN-Library durchsuchensend deine Daten bei non-blocking Sockets leider NICHT garantiert komplett verschickt:

...

Achso: Den TCP Stack direkt buffern zu lassen - wie du es momentan machst -, ist meiner Meinung nach keine gute Idee. Die Buffergröße hängt von verschiedenen Parametern ab und kann sich von System zu System stark unterscheiden. Wenn du dann versuchst eine Nachricht zu schicken, die nicht komplett in den Buffer passt, wird deine Verbindung dauerhaft blockiert sein, da du in diesem Falle ja niemals Daten ausliest (also auch keinen neuen Platz im Receive-Buffer schaffst).
Zumindest geben SendStream immer True zurück. Also sollten sie erfolgreich verlaufen.
Die Datenmengen sind derzeit auch sehr klein, so dass diese kein Problem darstellen sollte.

Ich gehe derzeit eher von einem Threading-Problem aus.

Aber ich schaue mir das die nächsten Tage nochmal genauer an.


Danke Euch!
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#35

AW: Spielwiese - SocketTest

  Alt 27. Dez 2016, 23:32
Also das Problem war hausgemacht durch die Umstellung auf Streams und einige kritische Zugriffe durch Threads.
Ich habe das jetzt bereinigt und es läuft augenscheinlich perfekt.

Anbei die wesentlichen Auszüge, falls es jemanden hilft.
Das komplette Framework werde ich hier nicht hochladen, da es scheinbar nicht sehr von Interesse ist.

Falls doch, schreibt eine pm.


Delphi-Quellcode:
procedure ...SendSLTo...(aSL: TStringList);
var
  MS: TMemoryStream;
  MSSize: LongInt;
begin
  MS := TMemoryStream.Create;
  aSL.SaveToStream(MS);
  MS.Seek(0, soBeginning);
  MSSize := MS.Size;
  fClientSocket.Socket.SendBuf(MSSize, SizeOf(MSSize));
  fClientSocket.Socket.SendStream(MS);
end;

procedure ...SocketClientRead(Sender: TObject; Socket: TCustomWinSocket);
const
  BufSize = 1024 * 10;
var
  Len: Integer;
  Bfr: Pointer;
begin
  GetMem(Bfr, BufSize);
  repeat
    Len := Socket.ReceiveBuf(Bfr^, BufSize);
    if (Len > 0) then
      fMessageHandlerServer.RegisterInBuffer(Bfr, Len, Socket);
  until (Len <= 0);
  FreeMem(Bfr);
end;

procedure ...RegisterInBuffer(const aBufr: Pointer; const aLen: Integer; const aConnection: TObject);
var
  lMS: TMemoryStream;
  lSL: TStringList;
  BreakFlag: Boolean;
begin
  fCS.Enter;
  try
    if (aLen > 0) then
    begin
      fMS.Seek(0, soEnd);
      fMS.Write(aBufr^, aLen);
    end;

    BreakFlag := False;
    repeat
      if (fBlockSize = 0) then
      begin
        if (fMSPos + SizeOf(fBlockSize) <= fMS.Size) then
        begin
          fMS.Position := fMSPos;
          fMS.Read(fBlockSize, SizeOf(fBlockSize));
          fMSPos := fMS.Position;
        end;
      end;

      if (fBlockSize > 0) then
      begin
        if (fMSPos + fBlockSize <= fMS.Size) then
        begin
          fMS.Position := fMSPos;
            lMS := TMemoryStream.Create;
            lMS.CopyFrom(fMS, fBlockSize);
            fMSPos := fMS.Position;
          lSL := TStringList.Create;
          lMS.Position := 0;
          lSL.LoadFromStream(lMS);
          LogSL('<==', '', lSL);
          RegisterInSL(lSL, aConnection);

          FreeAndNil(lMS);
          fBlockSize := 0;
        end
        else
          BreakFlag := True;
      end
      else
        BreakFlag := True;
    until (BreakFlag);

    if (fBlockSize = 0) then
    begin
      fMS.Clear;
      fMSPos := 0;
    end;
  finally
    fCS.Leave;
  end;
end;

procedure ...DoRegisterInSL(out aDone: Boolean);
var
  lSL: TStringList;
  lMessage: IsoMessage;
  lConnectionStringList: IsoConnectionStringList;
  lConnection: TObject;
begin
  aDone := False;
  lConnectionStringList := fMessageStringList.GetNextConnectionStringList;
  if Assigned(lConnectionStringList) then
  begin
    lConnection := lConnectionStringList.Connection;
    lSL := lConnectionStringList.GetNextSL;
    if Assigned(lSL) then
    begin
      if Assigned(fMessageImporter) then
      begin
        fMessageImporter.ResolveSLToMessage(lSL, lConnection, lMessage);
        if Assigned(lMessage) then
        begin
          fInMessageList.Add(lMessage);
          aDone := True;
        end;
      end;
      FreeAndNil(lSL);
    end;
  end;
end;
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#36

AW: Spielwiese - SocketTest

  Alt 24. Mär 2017, 21:25
Bei dem letzten veröffentlichten Stand gibt es noch Probleme bei umfangreichen gleichzeitigen Zugriffen durch mehrere Clients, da bis dahin nur ein Puffer für eingehende Streams verwendet wurde.
Das nur als Info, falls jemand bei Tests Probleme bekommt.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 4 von 4   « Erste     234   


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 22:53 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz