Websock

06/07/2011 - 08:26 von W. Wolf | Report spam
Bin so frei und verlagere das mal in einen neuen Thread. Hier sind wir
inzwischen màchtig OT ;-)

Am 05.07.2011 13:20, schrieb Schmidt:

Am 04.07.2011 10:18, schrieb W. Wolf:



Was willst Du denn auf Basis von WebSockets bauen?


Nun ja, das hast Du in den folgenden Zeilen ja fast schon selbst
beantwortet. Wenn die Kommunikation zwischen UI und Logik ausschließlich
über "*Sock" stattfindet, so wird diese UI komplett unabhàngig vom
Datenlieferant. Ob die Anwendung dann im Browser oder das
Browser-Control in die App eingebettet ist, spielt keine entscheidende
Rolle mehr.
Nun ist aber das HTTP-Protokoll statuslos, wie wir wissen. Auf die Idee
mit den WebSock bin ich gekommen als ich den c't Artikel zu HTML5&JS /
.Net gelesen habe. Unsere aktuellen Browser sind noch nicht so weit,
aber es ist zu erwarten, dass die nàchsten Versionen Websockets
unterstützen werden. Wenn das auch "dein" WebKit könnte, so wàren wir
hier einen ganz entscheidenden Schritt weiter. Auf die direkte
DOM-Manipulation aus der Anwendung heraus könnte verzichtet werden. Man
könnte sich einen effektiven und transparenten Mechanismus zum
Nachrichtenaustausch überlegen und hàtte damit eine zeitgemàße
Architektur die ein paar Jahre halten könnte.



Ok, dem steht (vor allem auch mit dem jetzt integrierten
WebServer direkt in der RC4-Dll) eigentlich nix im Wege.



Sehr gut! Eine serverseitige Websockets-Unterstützung kann man sich
damit wahrscheinlich auch selber bauen. Habe mich bislang nur mit dem
Webserver-Fàhigkeiten aus RC3 beschàftigt. Ändert sich in RC4 was
gravierendes? Die grundlegenden Standards sind hier ja bereits
enthalten. Für eine lokale Kommunikation über localhost mit der eigenen
Anwendung ist RC3 schon bestens zu gebrauchen. Habe noch nicht getestet
wann und wo VB mit RC3 einknickt wenn der Webport sich nach "außen"
öffnet und sich das ganze Intranet darauf stürzt. Mit Winsock konnte ich
den unternehmensinternen Bedarf bisher ausreichend decken.


Man kann also eine MyWebApp.exe in VB6 erstellen,
die den serverseitigen Code in entsprechenden (z.B. Private)
Klassen komplett enthàlt und dann mit dem ebenfalls
in der Exe gehosteten "UI-Form mit Browser-Ctl"
Ping-Pong spielt.



Genau!


Das heisst, in einem solchen Client(BrowserCtl) und
Server(VB6-Klassen) vereinenden Executable steht
Dir (aus den "Server-Klassen heraus") alles offen,
was in normalen VB-Apps an Libraries sonst auch
Verwendung finden kann (z.B. Winsock.ocx oder auch -API).



Stimmt!



Performancemàßig (gerade gemessen) schafft man über
"127.0.0.1" (also "localhost" bzw. das LoopBack-Interface)
so in etwa 250 synchrone Requests/sec (WebKit und IE9) oder
330 Requests/sec (FireFox Nightly 7.0) bei kleinen
jQuery-basierten "ajax->JSON-RPC-Requests" (synchron,
inkl. JSON-Dekodierung in eine Collection auf Serverseite,
also bereits "mit VB-Komfort").



Das sind doch sehr gute Zahlen. Dabei verursacht ein HTTP-Request, wohl
auch eine ajax-Anfrage noch immer jede Menge Overhead, welcher mittels
Websock noch mal erheblich reduziert werden kann. Vielleicht lernen
zukünftige Browser, bzw. JS, auch den Umgang mit Binàrdaten. Du hast
irgendwo geschrieben, dass so was wie Tabellen bereits irgendwo
integriert sind. Das würde den Datenaustausch zwischen den Schichten
noch mal effektiver machen.


Also so um die 3-4msec benötigt ein kleiner JSON-RPC-
Roundtrip (z.B. für ein serverseitiges Event) ...
im GBit-LAN wàre dann nur etwa 1msec Latenz oben
draufzuschlagen. So viel schlechter sind diese
(http+jQuery+JSON-Overhead) Latenzzeiten über Sockets
(verglichen mit normalem Windows-Messaging) also eigentlich nicht
(etwa um Faktor 10 schlechter, aber immer noch weit
unter den Screen-Refresh-Intervallen, die so
bei 12-15msec liegen).



Klingt auch schon sehr gut. Und bis die Möglichkeit der
Websock-Verwendung reif ist, ist der JSON-RPC-Ansatz ein sehr guter. Bei
einem eventuellen spàteren Wechsel zu Websock muss ja nicht viel
geàndert werden.


Je weniger Du in diesem Modus direkt am Browser-Control
(am clientseitigen DOM mittels *VB-Code*) noch zusàtzlich
herumschraubst, desto leichter ist eine solche Anwendung
dann auch "aufspreizbar" zwecks Verwendung in einem
normalen Browser-Client.
Bei ausschließlich aus den Server-Klassen heraus
passierender Fütterung des internen Browser-Controls
wàre der "Split-Aufwand" dann also 0 (für eine
z.B. im LAN laufende "echte Browser-Anwendung").




Du schaffst es perfekt meine Überlegungen in Sàtze zu überführen... ;-)))

Schönen Gruß
W. Wolf
 

Lesen sie die antworten

#1 W. Wolf
06/07/2011 - 10:27 | Warnen spam
Hallo,

Nachtrag:
http://heise.de/-1260189

Schönen Gruß
W. Wolf

Ähnliche fragen