Chat mit Synapse

Alle Fragen zur Netzwerkkommunikation
schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Das haben die schon x-mal versucht, ohne daß das aber eine wirklichen Erfolg gebracht hätte. Du mußt dir mal ansehen was das System treiben muß um eine solche Anfrage zu erledigen. Das wurzelt sich da durch mehrere Datenbanken und muß dann noch zwischendurch Zustandsprüfungen machen. Bis das fertig ist vergeht schon seine Zeit, die ist aber eben auch nicht vorhersagbar. Bei älteren Anwendungen kam dann noch hinzu, das während der Anfrage meistens auch noch die Anwendung gefreezt war, was das ganze nicht gerade angenehmer gemacht hat. Viele von den Dingern laufen heute noch.

Ich bin da eher für die elgante Lösung die auch garantiert zum Erfolg führt. Aber da hat halt jeder seine eigene Philosophie.

Schade das du das Stück Quellcode aus dem Zusammenhang gerissen hast, aber trotzdem meinen tief empfundenen Dank für den Hinweis. Vielleicht freunde ich mich ja mit den Synapse doch noch an.

Wie war das eigentlich mit deinen RIMM's, müssen die zwingend Samsung sein wegen der Synchronisierung?
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Benutzeravatar
theo
Beiträge: 10497
Registriert: Mo 11. Sep 2006, 19:01

Beitrag von theo »

schnullerbacke hat geschrieben:Das haben die schon x-mal versucht, ohne daß das aber eine wirklichen Erfolg gebracht hätte. Du mußt dir mal ansehen was das System treiben muß um eine solche Anfrage zu erledigen.

Ja, nur würde ich da einfach mal drauf tippen, dass das Problem nicht in TCP/IP zu suchen (und zu lösen) ist, sondern im Datenbankteil oder was-auch-immer.

Und bevor man den Client zum Server macht, gäbe es andere Ansätze wie z.B.
(spontan-Einfall): Der Client gibt dem Server eine Abfrage in Auftrag, Erhält vom Server ein "Ticket" (ID) und die momentane durchschnittliche Wartezeit und verabschiedet sich wieder. Nach der Wartezeit holt der Client mit der ID das Resultat ab.

Aber dadurch verbessert sich die Gesamtperformance auch nicht wirklich, genau wie bei deinem Vorschlag.

schnullerbacke hat geschrieben:Schade das du das Stück Quellcode aus dem Zusammenhang gerissen hast, aber trotzdem meinen tief empfundenen Dank für den Hinweis. Vielleicht freunde ich mich ja mit den Synapse doch noch an.

Der Zusammenhang bei Synapse ist im Zweifel immer blcksock.pas.
Hier genauer:
procedure TBlockSocket.SetDelayedOption(const Value: TSynaOption);

Nach "aussen hin" ist es aber ein Property:

Code: Alles auswählen

{:If @True, turn class to non-blocking mode. Not all functions are working
     properly in this mode, you must know exactly what you are doing! However
     when you have big experience with non-blocking programming, then you can
     optimise your program by non-block mode!}

    property NonBlockMode: Boolean read FNonBlockMode Write SetNonBlockMode;


schnullerbacke hat geschrieben:Wie war das eigentlich mit deinen RIMM's, müssen die zwingend Samsung sein wegen der Synchronisierung?


Das Problem ist: ich weiss es nicht. Ich hab nur mal gelesen, dass z.B. NEC oder Kingston nicht so gut funzen. Wäre halt Risiko und hängt deshalb vom Preis ab.

Aber vielen Dank für deine Bemühungen!

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Bliebe noch Infineon, die waren verhältnismäßig ordentlich. Ich guck mir das morgen mal an, mal sehen was sich machen läßt.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Antworten