Nonblocking/Threadblocking?

[_p_]

ich mal wieder

also geht um die komponente tserversocket die ja die eigenschaft type hat

hab mir schon mal die hilfe durchgelesen, aber wurde daraus genausowenig schlau wie von google und der forensuche

wo genau is der effektive unterschied zwischen nonblocking und threadblocking?
was hab ich davon dass die connections einzelne "threads" sind?

und was wäre besser für eine anwendung die viel daten, teilweise gleichzeit hin und herschiebt?

wäre nett wenn mri jemand kurz helfen könnte
geht um nen onlinekartenspiel mt integriertem chat usw.

thx

p

[hboy]

nonblocking funktioniert nicht mit streams.

[Muetze1]

Moin!

Zitat:

Zitat von hboy

nonblocking funktioniert nicht mit streams.

Wer hat dir denn das erzählt? Siehe mein Chat auf meiner HP - beide (TServerSocket und TClientSocket) arbeiten stNonBlocking und arbeiten nur mit Streams - und funktionieren sogar - man glaubt es kaum (weil nach deiner Ausage stellt dies ein Wunder dar). Daher würde mich die Begründung mal interessieren bzw. wie du auf diese Aussage kommst.

MfG
Muetze1

[hboy]

probleme mit nonblocking socket bei TWinSocketStream


Laut Hilfe auch:

Delphi-Quellcode:

Hinweis:   TWinSocketStream kann nicht in Verbindung mit nicht blockierenden Sockets eingesetzt werden.

[Muetze1]

Moin!

Ja und? Warum sollte man dieses nun auf die TCustomWinSockets verallgemeinern? Bei den normalen TServerSocket und TClientSocket funktionieren die Methoden einwandfrei und TCustomWinStream musst du ja selber instanziieren und benutzen - also einfach nicht benutzen. Deren Vorteil ist nicht so gross als wenn es sich lohnen würde...

MfG
Muetze1

[hboy]

kannst mir ja mal mit meinem thread-problem helfen ;)

[Muetze1]

Moin!

Zitat:

Zitat von hboy

kannst mir ja mal mit meinem thread-problem helfen ;)

Welches? Oder bist du auch "fadz" ??

MfG
Muetze1

[hardy1234]

hey hboy,

da streiten sich die jungs hier um des Kaisers Bart und vergessen das Eigentliche.
Beim Threadblocking kann der Server-Socket Events entgegennehmen und dann die Verarbeitung an einen Thread je Client übergeben. Der Vorteil liegt auf der Hand, jeder Thread erledigt seine Arbeit und beendet sich dann selbst, während der Serverthread weiter Anforderungen annehmen kann. Gemeint ist also, das der Serverthread geblockt wird und Du die Daten in einer Rutsche einlesen kannst.

Bei Non-Blocking kommt noch das Problem hinzu, das Server und Client für das Lesen und Schreiben von Daten selbst verantwortlich sind. Allgemein geht das dann nur mit einem Timer.

Wenn die Anwendung also eher selten Daten empfängt oder Du möchtest nur auf das Tatsächliche auftauchen von Daten am Server reagieren, ist Threadblocking die erste Wahl.

Gruß

Hardy

[hboy]

Zitat:

Zitat von Muetze1

Moin!

Zitat:

Zitat von hboy

kannst mir ja mal mit meinem thread-problem helfen ;)

Welches? Oder bist du auch "fadz" ??

MfG
Muetze1

1. was soll ich sein ?
2. http://www.delphipraxis.net/internal...903&highlight=
3. gehört das nicht hier rein und deswegen schluss damit.

[Jackie1983]

habe dazu auch noch ne frage. Ok Threadblocking heist das jeder client im separaten thread behandelt wird.
Wenn ich type auf Threadblocking stelle passiert aber nichts, es wird kein connect kein read event aufgerufen nichts, was muss ich da machen?

Muss ich hier in einem Thread abfragen ob neue daten da sind?
Keinen plan....

[helgew]

hi,

damals war ich dabei, einen webserver zu programmieren, den ich mittlerweile schon über vier Jahre lang einsetze :)
Zunächst startet man einen neuen Behandlungsthread durch

Delphi-Quellcode:

procedure TForm1.ServerSocket1GetThread(Sender: TObject;
  ClientSocket: TServerClientWinSocket;
  var SocketThread: TServerClientThread);
begin
// [...]
  SocketThread := nil;
  SocketThread := TSendThread.Create(true,ClientSocket); // create susepended
  while not assigned(SocketThread) do Application.ProcessMessages;
  (SocketThread as TSendThread).MemoThread := form1.MyThread; // Callback-Information setzen
  (SocketThread as TSendThread).processline :=memo2.Lines.Count-1; // http-request
  (SocketThread as TSendThread).Resume; // threadausführung starten
end;

im Thread selbst kann man dann WinSocketStreams bearbeiten. Es muss allerdings, wie vielleicht schon aus der Klassenbezeichung zu vermuten, eine eigene Threadklasse abgeleitet werden:

Delphi-Quellcode:

type TSendThread= Class(TServerClientThread)
    Procedure ClientExecute; override;
    function SendFile(fn: string):boolean;
  public
    MemoThread: Cardinal;
    processline: integer;
    request: string;
    replyhdr: string;
    fn: string;
    fsize: longint;
    starttime: longint;
  end;

Der SocketStream hängt dann beim Schreiben nicht alles auf. Zu deiner Frage: Das Timing des Schreibens wird durch den SocketStream geregelt. Für Leseoperationen gilt afaik das gleiche, sprich du gibst eine Anzahl zu lesender bytes vor und einen timeout und der Thread fährt dann fort, wenn die Daten gelesen oder die Zeit abgelaufen ist. Ich bin mittlerweile nicht mehr so sehr in der Thematik drin, da ich in letzter Zeit vorwiegend im Bereich Signal- und Bildverarbeitung unterwegs bin. Vielleicht schreibt ja noch einer der Cracks hier was dazu :)

[Jackie1983]

gibt es da nicht irgend wo ein tut eventuell zu.
Habe schon gegoogelt aber nichts gefunden.

[uoeb7gp]

Hi, als Tutorial mal meine Synchrone Serveranwendung.

Have a lot of fun!

[alzaimar]

Zitat:

Zitat von helgew

Delphi-Quellcode:

// [...]
{1} SocketThread := nil;
{2} SocketThread := TSendThread.Create(true,ClientSocket); // create susepended
{3} while not assigned(SocketThread) do Application.ProcessMessages;

Kannst Du mir den Sinn von (1) und (3) erklären?

[himitsu]

OK, die 1 ist klar:
damit im Fehlerfall (Klasse konnte nicht erstellt werden) die Variable NIL ist.


Aber die 3 ist sinnlos, da entweder Exception und man kommt dort nie vorbei
und wenn es dort vorbei kommt, dann wurde auf jeden Fall eine Klasse erstellt und zwar schon vor der Schleife.

[helgew]

stimmt, (3) ist reichlich sinnfrei, aber frag mich nicht, was ich mir vor Jahren dabei gedacht hatte... vielleicht wars auch nur ein lustiger Versuch während der Fehlersuche, den ich danach nicht mehr rauskommentiert oder gelöscht habe. Vergiss die Zeile einfach.

es könnte aber auch etwas mit TCollection.Create und IDesignerNotify.Notification zu tun haben, dass da etwas asynchron abläuft. Hey, ich wollte nur ein paar Hinweise geben.