Prinzipielle Frage zu HTTP-basiertem Datenaustasuch.
-
Hallo,
bei HTTP-basierten Anwendungen (HTML, SOAP, WebServices, ...) schickt ja immer der Client einen Request zum Server und der antwortet dann mit irgendwelchen Daten.
Gibt es denn irgendeine Möglichkeit/Anwendung, wo nun andersherum der Server den Client über irgendwelche Ereignisse benachrichtigen kann?
Ist da was in HTTP dafür vorgesehen? Oder geht das prinzipiell nicht?
(Wäre ja technisch machbar, wenn sich der Server die Verbindung zum Client "merkt" bzw. offenhält)
Wie wird das z.B. bei Webservices gehandhabt?
-
Also AFAIK sind Verbindungen immer Clientseitig wenns um HTTP geht. Allerdings könntest du einen Webserver schreiben... [...]
Is halt anders als bei IRC zum beispiel, wo es für den Server WiCHTIG ist, das er weiss das du online bist.
Aber bei HTTP Servern wäre mir soetwas nicht bekannt.
-
scrontch schrieb:
Gibt es denn irgendeine Möglichkeit/Anwendung, wo nun andersherum der Server den Client über irgendwelche Ereignisse benachrichtigen kann?
Siehe 'HTML Chats' - das Problem hier ist, dass die Verbindung immer bestehen bleiben muss - was natürlich große Nachteile hat.
Ist da was in HTTP dafür vorgesehen? Oder geht das prinzipiell nicht?
Der Server kann keine Verbindung zum Client aufbauen (normale Browser agieren ja auch nicht als Server, dh lauschen nicht)
Einzig im HTTP Header gibt es eben bestimmte Status Meldungen ala "Permanently Moved", "redirect to", etc.
(Wäre ja technisch machbar, wenn sich der Server die Verbindung zum Client "merkt" bzw. offenhält)
Nicht mit HTTP - denn HTTP ist nicht Connection basierend, sondern es wird die Verbindung vom Client 'on demand' gemacht. Das ist der Gedanke dahinter.
Ein anderes Protokoll zu nehmen bzw. zu entwerfen sollte aber kein Problem sein (lediglich das Firewall-Problem hast du dann - viele Firmen oÄ sperren halt alles ausser HTTP und SMTP/POP)
Wie wird das z.B. bei Webservices gehandhabt?
Der Client will etwas vom Webservice - deshalb ist es ja kein Problem, wenn der Client die Anfrage sendet.
-
Bei HTML-Chats muss die verbindung nicht bestehen bleiben. Gibt es ja auch nicht.
Da fragt der Client immer zu einer bestimmten Zeit ab ob was neues da ist.Klar kann man den Webserver dazu bringen eine verbindung zu einem Client aufzubauen. Es gibt z.B. bei PHP die Socket-Funktionen. Wobei es dann eigentlich ein C/S/C ist. Der letzte Client ist aber dann wieder ein Server.
Kommt immer auf den Zweck des Dienstes an.
-
Unix-Tom schrieb:
Bei HTML-Chats muss die verbindung nicht bestehen bleiben. Gibt es ja auch nicht.
Da fragt der Client immer zu einer bestimmten Zeit ab ob was neues da ist.OK - das zieht eben langwieriges Nachladen mit sich - ist auch nicht das gelbe vom EI. Aber stimmt, daran habe ich nicht gedacht - ich hatte 'Streaming HTML' im Sinn.
-
Shade Of Mine schrieb:
- ich hatte 'Streaming HTML' im Sinn.
Wie soll das gehen?
Hab ich eine Technik verpasst die eigentlich gut gebrauchen könnte.
-
eine "billige" methode wäre, die verbindung einfach offenzuhalten.
hatte ich vor ein paar jahren mal interessant gefunden, aber damals war es browserabhängig, einige warten auf das ende der übertragung, manche fangen gleich an, darzustellen.
hier eine interessante auseinandersetzung über sinn oder nicht.
http://forum.de.selfhtml.org/archiv/2003/3/40634/hat jetzt nichts mit streaming von audio oder video zutun.
-
Unix-Tom schrieb:
Hab ich eine Technik verpasst die eigentlich gut gebrauchen könnte.
Nicht wirklich. Streaming HTML bedeutet einfach die Verbindung nie zu schliessen und immer mehr Daten zu senden. Offiziell existiert 'Streaming HTML' nicht, allerdings kommen alle Browser damit klar.
Der Vorteil ist, dass man weniger neu laden (nämlich nur das eingabefeld, wenn der User etwas geschrieben hat) hat - der Nachteil, dass man pro User einen Socket braucht...
