Chat mit Synapse

[Ati]

Hallo zusammen,

nach langer Krankheit und anderen Problemchen bin ich mal wieder zurück an der Lazarus-Front. Da ich keine Lust habe nach der Installation einer neuen Version (aktuell ja 0.9.20) immer wieder Indy neu zu installieren habe ich mich mal an Synapse herangewagt. Da ich kein Profi bin habe ich echt Schwierigkeiten mit diesen units umzugehen. Habe mal als ganz kleinen Test per "httpgettext" eine Webseite abgefragt und das funzte auch. Jetzt wollte ich mal zu Testzwecken ein kleines Chatprogramm schreiben und jetzt stehe ich da mit Hosen unten. Habe mir mal die Hilfe durchgelesen und ehrlich gesagt weiß ich noch nichtmal welche Unit ich benutzen soll. All das was einem von Indy ja abgenommen wird muss man ja hier selber machen und ich sehe das auch als Lehrmöglichkeit nur bin ich aktuell total erschlagen von Synapse. Also ein Schubs in die richtige Richtung wäre sehr nett.

Danke
Ati

[EugenE]

mit synapse fand ich auch nich die richtigen funktionen aber mit INet kannste einen chat machen , habe ich auch gemacht , naja eher von einem tutorial xD

[theo]

Synapse ist meiner Meinung nach die beste TCP/IP Library mit dem besten Support.
Das grösste Umdenken wenn du von Indy oder ICS kommst besteht in der Tatsache, dass es bei Synapse so gut wie keine Events gibt.
Du musst einfach nur Kommando an Kommando reihen.

Das andere ist, dass Synapse nicht viel mehr sein will als als eine Library für socket communication.
Krimskrams wie Indy hat findest du da nicht. Lukas Gebauer (der Entwickler von Synapse) kümmert sich z.B. nicht um Threading Klassen etc. Das ist in der Verantwortung des Entwicklers. Dafür kapiert man nach etwas Eingewöhnungzeit den Code und kriegt ein Gefühl dafür, was abgeht. Wenn bei Indy was nicht ging wie ich wollte, musste ich echt passen, weil ich mich in dem Sammelsurium von Code nie zurechtfand. Bei Synapse baue ich meine Vorstellungen einfach in den Basis-Code ein, weil er verständlich ist, oder leite ein Klasse ab, die tut was ich will.
Einige Vorschläge habe ich auch schon an Lukas weitergesandt, und ein paar davon waren dann im nächsten Synasnap auch tatsächlich wiederzufinden.

Lukas Gebauer hat eine genaue Vorstellung davon, was Synapse sein soll und vor allem was nicht.

Wo starten? Ich würde für Dein Anliegen mal TTCPBlockSocket in Betracht ziehen (Unit blcksock)
http://synapse.ararat.cz/docs/help/blck ... ocket.html

beachte bitte auch die Vererbung von TBlockSocket http://synapse.ararat.cz/docs/help/blck ... ocket.html

Wie man einen einfachsten Multi Threaded Server bastelt, siehst du in der Echo Demo welche in
http://synapse.ararat.cz/files/synapse.zip enthalten ist.

Je nach Modell kommt vielleicht auch UDP in Frage http://synapse.ararat.cz/docs/help/blck ... ocket.html da kenne ich mich aber gar nicht aus.

Fragen kannst du in http://synapse.ararat.cz/list.htm stellen

[theo]

Ich hab dir hier mal ne einfache Chat Demo mit Synapse, basierend auf der Echo Demo gebastelt.
Da gibt's noch vieles zu verbessern

[Christian]

voll und ganz zustimm ich hab lukas vor 3 Monaten eine geänderte Synaser unit geschickt die unter wince funktioniert dazu hab ich leider aber bis heute keine antwort

[Ati]

Hallo,
erstmal Danke für die prompten Antworten. Das Bsp. funktioniert wirklich gut. Jedoch mußte ich mal wieder feststellen, dass mir viel elementares Wissen fehlt. Die unit1 habe ich noch verstanden aber als ich mir die chatserv angeguckt habe war nur noch Bahnhof angesagt.

[theo]

Die unit1 habe ich noch verstanden aber als ich mir die chatserv angeguckt habe war nur noch Bahnhof angesagt.

Wo hast du denn Probleme? Mit Synapse oder mit Threads?

[Ati]

Ich fürchte eher mit dem ganzen. Wobei synapse so laaangsam klarer wird. Habe mir mal ein etwas einfacheres Bsp gemacht. Einfach mal nur ne Mail senden..hat sogar geklappt.

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
var host,from:string;
    body:TStrings;
begin
  body:=TStringlist.Create();
  host:='xx.xx.x.x';
  from:='mig';
  body.Add(edit3.Text);
  sendto(from,edit1.Text,edit2.Text,host,body);
 
 
end;

Nur was Du da in der chatserv gezaubert hast entzieht sich noch meinem Verständnis bzw. wäre ich nie im Leben selber drauf gekommen. Tja so ist das wenn man sonst immer nur mit fertigen Komponenten gearbeitet hat.

[Christian]

In der synapse wiki findest du einfache Server und Clients mit TCPBlockSock erklärt

[Ati]

Hmm werde nochmal nachschauen....habe ich dann wohl übersehen.

[schnullerbacke]

Na ja theo,

nen Chat mit udp ist so ne sache. Wenn du etwas größere Datenmengen zulassen willst, also mehr als ein IP-Package je Datensatz, dann wird das mit udp sehr aufwendig. Da müßte man dann ein eigenes Package-Handling einbauen. Package-Ident auslesen und gucken ob alle da sind und im Zweifel noch sortieren. Das dürfte wohl für den Anfang etwas zu grober Stoff werden.

War das mit Synapse nicht so, daß das geblockte Sockets sind? Das war einer der Hauptgründe der mich abgehalten hat Synapse zu benutzen. Im Grunde möchte ich beim Chat eigentlich auf die Trennung zwischen Client und Server ganz verzichten. Jeder Client sollte auch Server sein können und der eigentlichte Server nur die Verbindungsdaten liefern. Dann das ganze mit NAT-Traversal durch den eventuell vorhandenen Router schleusen. SSL haste dann mehr oder weniger automatisch.

Ansonsten geb ich dir ja Recht, die Indy's sind schon ein wenig undurchsichtig. Die Doku dazu macht das auch kaum besser. Das schlimmste an den Dingern ist diese elende ClosedGracefully-Kiste. Da hab ich ne Weile dran gesessen bis ich das ausgehebelt hatte. Das hat einem sonst ständig den Client dichtgemacht was beim Chat ja nun tödlich ist. Das ist doch nun bei so einer Anwendung brachialer Schwachsinn den Client alle 30 Sekunden oder irgendeine andere Zeit beim Server anfragen zu lassen ob was da ist. Alleine schon die Tatsache das der Server dauernde Connect-Disconnect Aktionen durchführen muß mit ständiger Prüfung ob das ein erlaubter Client ist, ist dermaßen viel Overhead, das der ab 50 Clients wohl grausam in die Knie geht.

[theo]

War das mit Synapse nicht so, daß das geblockte Sockets sind? Das war einer der Hauptgründe der mich abgehalten hat Synapse zu benutzen.

Das ist Indy aber auch. ICS hingegen nicht.

Im Grunde möchte ich beim Chat eigentlich auf die Trennung zwischen Client und Server ganz verzichten. Jeder Client sollte auch Server sein können

Wieso soll das nicht gehen mit Synapse? Die kleine dumme Demo oben spielt ja auch beide Rollen.

Das ist doch nun bei so einer Anwendung brachialer Schwachsinn den Client alle 30 Sekunden oder irgendeine andere Zeit beim Server anfragen zu lassen ob was da ist.

Da bin ich mir gar nicht mal so sicher. Für jeden Client 'nen Thread am Laufen halten obwohl "selten" was passiert ist auch nicht gerade "billig".

[schnullerbacke]

@theo

1. Bei den Indy's kann man das aber unterbinden. Ist zwar nicht ganz einfach aber geht.

2. Mit Synapse mag das ja gehen, womit ich wieder bei 1 bin. Es gibt für mich keinen erkennbaren Grund, warum sich ein Server nicht als Client bei einem anderen Server anmelden können sollte. Aber so ziemlich alle Implementierungen verhindern das der Server seinerseits Verbindungen zu anderen Servern aufnehmen kann, indem sie den Connect nicht z.V. stellen. Erklären konnte mir das bisher niemand.

3. Na ja, bei Linux ist das eher das kleinere Problem wenn man sonst auf der Kiste nix weiter laufen hat. Bei Windoofs geb ich dir Recht, das könnte eher schlecht damit umgehen. Man muß ja auch mal einen Blick auf die Zahlen werfen, mehr als 150 gleichzeitige Verbindungen dürften eher die Ausnahme sein, das relativiert das dann schon. Nur laufen tut eben Serverseitig immer was, ruhiger geht es da eher bei den Clients zu.

Hintergrund bei meiner Betrachtung ist ein System das hier im Hamburger Hafen läuft (oder besser nicht läuft). Unter normalen Umständen sollte jeder interessierte sich bei einem Informationssystem Daten über bestimmte Schiffsladungen abholen können. Im Idealfall würde man also ohne großes Hin und Her herausbekommen ob eine Ladung bereits da ist oder zumindest wann sie wahrscheinlich eintrudelt. Damit sollte eigentlich die Zollabwicklung beschleunigt werden, die könnte damit eigentlich bis zu einem bestimmten Punkt papierfrei erledigt werden.

Tatsache ist, das die Anfragen beim System aber häufig erst nach einer gewissen Wartezeit beantwortet werden können, was einen bei der Datenmenge auch nicht wundern kann. Meistens rumpeln die dann Prompt auf einen Timeout und müssen die Anfragen ständig wiederholen, das führt aber eben auch dann nur selten zum Erfolg. Läßt man die Schranke beim Client fallen und macht den ebenfalls zum Server, dann kann der Server die Anfrage abarbeiten und später das Ergebnis dem Client übergeben ohne das es zu den Timeout-Problemen kommt. Dazu ist dann kaum mehr nötig als eine URL bei dyndns.org oder ähnlich. VPN wäre genauso denkbar.

[Christian]

zu 2. warum denn ? das geht doch mit Synapse relativ simpel dort hast du doch von hause aus keine Server und Clientimplementierungen lediglich nen Sock der in beide Richtungen senden und empfangen kann.

[theo]

1. Bei den Indy's kann man das aber unterbinden. Ist zwar nicht ganz einfach aber geht.

Kann man mit Synapse auch:

Code: Alles auswählen

SOT_NonBlock:
      begin
        FNonBlockMode := Value.Enabled;
        x := Ord(FNonBlockMode);
        synsock.IoctlSocket(FSocket, FIONBIO, x);
      end;

Ist aber auch eher was für Cowboys...

Tatsache ist, das die Anfragen beim System aber häufig erst nach einer gewissen Wartezeit beantwortet werden können, was einen bei der Datenmenge auch nicht wundern kann. Meistens rumpeln die dann Prompt auf einen Timeout

Dann würde ich als erste Massnahme den Timeout erhöhen, bevor ich mir da 'nen Kopf mache. Oder noch besser die Bearbeitung beschleunigen.