Hallo!
Ich bin immer ein wenig neugierig. So möchte ich mal wissen, wie ein Chat programmiert ist. Welche Programme oder Programmiersprachen würde ich benötigen, um selbst einen Chat zu erstellen? Welche Voraussetzungen muß mein Provider erfüllen?
Im Voraus schon mal Danke!
Guido
Hi,
wie ein Chat programmiert ist.
das zugrundeliegende Protokoll, IRC, ist in RFC 1459 (http://www.ietf.org/rfc/rfc1459.txt) sowie den RFCs 2810 bis 2813 (URLs analog) definiert. Ein Chat besteht aus Server und Client(s), die sich nach diesem Protokoll richten. Weitere Stichworte sind z.B. TCP/IP und Sockets.
Welche Programme oder
Programmiersprachen würde ich benötigen, um selbst einen Chat
zu erstellen?
Es ist quasi egal, welche Programmiersprache Du benutzt - am Ende werden Server- und Client-Software eh kompiliert (das ist jedenfalls sinnvoll). Einzelne Sprachen haben natürlich Vor- und Nachteile. Ich kann Dir nur von Perl sagen, dass es dafür diverse Module gibt, die Dir den Umgang mit Sockets, den Aufbau eines Servers und sogar die Nutzung von IRC erleichtern.
Welche Voraussetzungen muß mein Provider erfüllen?
Er muss Dir erlauben, einen eigenen nicht-HTTP-Server aufzusetzen. HTTP ist für einen Chat denkbar ungeeignet[1], ein entsprechender Server kann Dir also nicht helfen.
Cheatah
[1] Ein Chat basiert auf Zuständen und benötigt bestehende Verbindungen; HTTP ist jedoch zustands- und verbindungslos. Darin einen Chat realisieren zu wollen ist wie der Versuch, mit einem Auto zu fliegen.
bisschen einseitig …
das zugrundeliegende Protokoll, IRC, ist in RFC 1459
(http://www.ietf.org/rfc/rfc1459.txt) sowie den RFCs 2810 bis
2813 (URLs analog) definiert. Ein Chat besteht aus Server und
Client(s), die sich nach diesem Protokoll richten. Weitere
Stichworte sind z.B. TCP/IP und Sockets.
das zugrundelegende Protokoll von IRC ist dort beschrieben … ich denke er meinte wohl eher einen Chat auf seiner homepage …
Welche Voraussetzungen muß mein Provider erfüllen?
Er muss Dir erlauben, einen eigenen nicht-HTTP-Server
aufzusetzen. HTTP ist für einen Chat denkbar ungeeignet[1],
ein entsprechender Server kann Dir also nicht helfen.
=> falsch
im Prinzip ist diese Antwort auch wieder auf IRC bezogen … es gibt im Netz tonnenweise chats die per Browser-funktionieren … und klar es gibt Java/Flash-Chats, die auf einem Client/Server-Prinzip basieren, aber es gibt ebensoviele, die das nicht tun …
Als Programmiersprachen für einen Webchat eignen sich Perl/C (CGI) oder PHP/ASP/JSP … für einen Chat (à la irc, icq, …) kannst du im Prinzip nehmen was du willst (solange die Sprache Client/Server unterstützt)
[1] Ein Chat basiert auf Zuständen und benötigt bestehende
Verbindungen; HTTP ist jedoch zustands- und verbindungslos.
noch nie was von flush gehört ? … bestehende verbindung sind damit ohne weiteres möglich (ohne ständigen reload) … somit
Darin einen Chat realisieren zu wollen ist wie der Versuch,
mit einem Auto zu fliegen.
und sie fliegen doch (giga.de, heise-chat, chatcity.de …) …
ein beispiel von einem „netten“ chat, der per icmp-packete funktioniert könnt ihr auf der page von meinem Freund Martin finden (www.codito.de) …
gruss
berni
Hi,
ich denke er meinte wohl eher einen Chat auf seiner homepage
ich weiß. Sowas ist aber eine Vergewaltigung des Protokolls und schafft zudem weitaus mehr Probleme, als man glaubt. Vom mikromalen Nutzen wegen des gewöhnlich quasi nicht existenten Benutzerkreises will ich gar nicht erst reden; das mag im Einzelfall auch anders sein.
Er muss Dir erlauben, einen eigenen nicht-HTTP-Server
aufzusetzen. HTTP ist für einen Chat denkbar ungeeignet[1],
ein entsprechender Server kann Dir also nicht helfen.=> falsch
Nicht falsch. HTTP ist für einen Chat nicht geeignet.
im Prinzip ist diese Antwort auch wieder auf IRC bezogen …
Natürlich, ich will schließlich helfen, und nicht eine Mogelpackung unterjubeln.
es
gibt im Netz tonnenweise chats die per Browser-funktionieren
Sie funktionieren nicht besser, als eine Zahnoperation unter Lachgas.
aber es gibt ebensoviele, die das nicht tun …
Deren Programmierer werden leider allzu selten in die Verantwortung gezogen. Seriöse Provider untersagen den Einsatz von HTTP-Chats.
Als Programmiersprachen für einen Webchat eignen sich
*Die* *Programmiersprache* *ist* *egal,* solange das Protokoll nicht geeignet ist.
[1] Ein Chat basiert auf Zuständen und benötigt bestehende
Verbindungen; HTTP ist jedoch zustands- und verbindungslos.noch nie was von flush gehört ?
Lies und begreife RFC 2616 und sag das noch mal. Lies außerdem etwas zu Timeout beim HTTP-Server (und begreife, warum das sinnvoll ist). Nebenbei darfst Du mir erklären, wie Du die unterschiedlichen Worker koordinieren willst. Ja, mit viel Aufwand kriegt man es hin - während man Server, Client, Leitungen und sämtliche dazwischenliegenden Systeme über Gebühr belastet.
… bestehende verbindung sind damit ohne weiteres möglich
Nein, sind sie nicht. Es wird krampfhaft verhindert, dass die Leitung geschlossen wird - womit der jeweilige Serverchild zu 100% belastet ist und nicht mehr für Requests verwendet werden kann. Der Server bedankt sich, indem er die Systemressourcen auslastet, obwohl er eigentlich gar nichts tut.
(ohne ständigen reload)
Ein Reload ist eine _neue_ Verbindung.
und sie fliegen doch (giga.de, heise-chat, chatcity.de …)
Ja, und wie sie fliegen. Siehe oben. Ein Chat über HTTP ist kriminell.
Cheatah
ich weiß. Sowas ist aber eine Vergewaltigung des Protokolls
und schafft zudem weitaus mehr Probleme, als man glaubt. Vom
mikromalen Nutzen wegen des gewöhnlich quasi nicht existenten
Benutzerkreises will ich gar nicht erst reden; das mag im
Einzelfall auch anders sein.
DAS sog. Protokol gibt es nicht … es gibt für ein Problem mehrere Lösung (du erinnerst mich ein wenig an einen verblendeten Fanatiker)
Er muss Dir erlauben, einen eigenen nicht-HTTP-Server
aufzusetzen. HTTP ist für einen Chat denkbar ungeeignet[1],
ein entsprechender Server kann Dir also nicht helfen.=> falsch
Nicht falsch. HTTP ist für einen Chat nicht geeignet.
das sagst du … (und das ist dann wohl deine subjektive Meinung PUNKT)
im Prinzip ist diese Antwort auch wieder auf IRC bezogen …
Natürlich, ich will schließlich helfen, und nicht eine
Mogelpackung unterjubeln.
jaja … aber nicht wenn du das ganze mit deiner persönlichen Meinung verfälschst … ich kann ebenso gut ein eigenes Chat-Protokol schreiben, so wie es mir passt … und solange du das nicht einsiehst solltest du vielleicht mal über die RFCs
es
gibt im Netz tonnenweise chats die per Browser-funktionierenSie funktionieren nicht besser, als eine Zahnoperation unter
Lachgas.
also gut ? … für viele jedenfalls gut genug für viele Leute …
aber es gibt ebensoviele, die das nicht tun …
Deren Programmierer werden leider allzu selten in die
Verantwortung gezogen. Seriöse Provider untersagen den Einsatz
von HTTP-Chats.
Programmierer, Verantwortung ?? hast du einen knall ?
ich darf mir doch einen eigenen Chat coden OHNE das du auch nur etwas dazu zu sagen hast …
Als Programmiersprachen für einen Webchat eignen sich
*Die* *Programmiersprache* *ist* *egal,* solange das Protokoll
nicht geeignet ist.
lies meinen Satz … (da steht GROSS Webchat …) … und das Protokol mag nicht ideal sein, aber es gibt 100’000 andere möglichkeiten OHNE IRC einen vernünftigen Chat aufzubauen (z.B. per Applet oder Flash und nem eigenen chat-server ?)
[1] Ein Chat basiert auf Zuständen und benötigt bestehende
Verbindungen; HTTP ist jedoch zustands- und verbindungslos.noch nie was von flush gehört ?
Lies und begreife RFC 2616 und sag das noch mal. Lies außerdem
etwas zu Timeout beim HTTP-Server (und begreife, warum das
sinnvoll ist). Nebenbei darfst Du mir erklären, wie Du die
unterschiedlichen Worker koordinieren willst. Ja, mit viel
Aufwand kriegt man es hin - während man Server, Client,
Leitungen und sämtliche dazwischenliegenden Systeme über
Gebühr belastet.
tut mir leid, ich hab genug zu lesen … und schreib mir nicht vor, was ich zu tun habe … scheint eh ein wenig dein Problem zu sein … (NUR du hast ja recht …)
… bestehende verbindung sind damit ohne weiteres möglich
Nein, sind sie nicht. Es wird krampfhaft verhindert, dass die
Leitung geschlossen wird - womit der jeweilige Serverchild zu
100% belastet ist und nicht mehr für Requests verwendet werden
kann. Der Server bedankt sich, indem er die Systemressourcen
auslastet, obwohl er eigentlich gar nichts tut.
was anderes ist dann eine BESTEHENDE Verbindung, als eine die nicht geschlossen wird ??
und das mit den 100 % ist FUD mein Freund …
(ohne ständigen reload)
Ein Reload ist eine _neue_ Verbindung.
was du nicht sagst … (übrigens der Text ist Schwarz)
und sie fliegen doch (giga.de, heise-chat, chatcity.de …)
Ja, und wie sie fliegen. Siehe oben. Ein Chat über HTTP ist
kriminell.
in deinen Augen, also hör auf deine Subjektive Meinung mit den Objektiven Fakten zu mischen … ich geb zu Ideal ist das ganze per HTTP nicht, aber machbar …
Cheatah
Berni
Hi,
DAS sog. Protokol gibt es nicht …
hm? Ich rede vom Hypertext Transfer Protocol, also HTTP. Du hast Recht, es gibt davon mehrere Versionen; aber in Hinsicht auf die grundlegende Arbeitsweise unterscheiden sie sich nicht. HTTP ist in allen bisherigen Versionen zustands- und verbindungslos.
es gibt für ein Problem mehrere Lösung
Ja. Dabei sind gewöhnlich .gute und schlechte.
(du erinnerst mich ein wenig an einen
verblendeten Fanatiker)
Tatsächlich. Vielleicht habe ich aber auch nur ein Fachverständnis entwickelt, das Dir noch fehlt? Klar kann man einen Drehstuhl auf einen Tisch stellen, um darüber die Glühbirne tauschen zu können (der Kumpel hält den Stuhl ja fest) - ein Sicherheitsexperte wird aber bei sowas vor Schreck leichenblass. Und das nicht, weil er fanatisch ist.
Nicht falsch. HTTP ist für einen Chat nicht geeignet.
das sagst du … (und das ist dann wohl deine subjektive
Meinung PUNKT)
Nein, es ist eine objektive Beurteilung der Fakten. Ein Chat benötigt bestehende Verbindungen, HTTP basiert auf _nicht_ bestehenden Verbindungen. Daran ist nicht das geringste subjektiv.
ich kann ebenso gut ein eigenes
Chat-Protokol schreiben, so wie es mir passt …
Klar, kannst Du gerne tun; IRC ist nicht das einzig denkbare Protokoll für einen Chat, es ist nur meine Empfehlung. Ein neues oder anderes Protokoll ändert aber nichts daran, dass HTTP sich nicht für einen Chat eignet.
und solange du
das nicht einsiehst solltest du vielleicht mal über die RFCs
Diesen Satz habe ich leider nicht verstanden.
Sie funktionieren nicht besser, als eine Zahnoperation unter
Lachgas.also gut ? … für viele jedenfalls gut genug
Ja; und diese vielen wissen leider nicht, was sie damit für Schaden anrichten.
Deren Programmierer werden leider allzu selten in die
Verantwortung gezogen. Seriöse Provider untersagen den Einsatz
von HTTP-Chats.Programmierer, Verantwortung ?? hast du einen knall ?
Nein, wieso?
ich darf mir doch einen eigenen Chat coden OHNE das du auch
nur etwas dazu zu sagen hast …
Natürlich kann ich Dir das nicht verbieten, und das will ich auch gar nicht. Wenn Du den Chat nur schreibst, hab ich da nichts gegen. Willst Du ihn aber _einsetzen_, stellst Du eine Gefahr für das Internet und die darin befindlichen Systeme dar.
Der Gesetzgeber verbietet nicht den Kauf oder Besitz eines Radarwarnsystems, es ist im Prinzip ja auch nichts schlimmes daran. Der _Einsatz_ eines solchen jedoch ist strafbar. Was bedauerlich ist ist, dass der Gesetzgeber in netzbezüglichen Dingen noch ziemlich unausgereifte Sprüche gefällt hat; im Grunde genommen wirst Du erst dann verantwortlich gemacht, wenn Du messbaren Schaden angerichtet hast. Der Betrieb von schadenverursachenden Systemen wird nicht unterbunden, darum gibt es auch noch solche Chats, wie Du sie hier verteidigst.
Als Programmiersprachen für einen Webchat eignen sich
*Die* *Programmiersprache* *ist* *egal,* solange das Protokoll
nicht geeignet ist.lies meinen Satz … (da steht GROSS Webchat …)
Lies meinen Satz, da steht auch Webchat, versteckt im Begriff „Protokoll“. Ein Chat über HTTP ist _unabhängig von der Programmiersprache_, ähm, suboptimal.
aber es gibt 100’000 andere
möglichkeiten OHNE IRC einen vernünftigen Chat aufzubauen
(z.B. per Applet oder Flash und nem eigenen chat-server ?)
Herrje - das _ist_ IRC! Nur weil ein Applet oder was immer über HTTP angefordert wurde heißt das noch lange nicht, dass es anschließend auch weiterhin über HTTP kommuniziert. Es gibt genügend Chat-Applets (ein Flash hierzu habe ich noch nicht gesehen, das heißt aber nichts), die über IRC und „einen eigenen Chat-Server“ arbeiten.
Lies und begreife RFC 2616 und sag das noch mal. […]
tut mir leid, ich hab genug zu lesen … und schreib mir
nicht vor, was ich zu tun habe …
Sorry, bisher ging ich davon aus, dass Du daran interessiert bist zu verstehen. Wenn Du nicht die Quellen lesen willst, in denen meine Äußerungen bestätigt werden, muss ich meine diesbezügliche Meinung wohl anpassen.
scheint eh ein wenig dein
Problem zu sein … (NUR du hast ja recht …)
Nein, nur Du liegst falsch. Die Fakten sind hier sehr einfach; es ist nicht mal eine Meinungsfrage. Wenn Du nicht begreifen möchtest, dass Dein Kenntnisstand über HTTP noch ausbaufähig ist, dann wirf mir doch bitte nicht vor, engstirnig zu sein. Ich bin mir einfach nur einer Tatsache bewusst, die Du noch nicht verinnerlicht hast.
was anderes ist dann eine BESTEHENDE Verbindung, als eine die
nicht geschlossen wird ??
Eine, die nicht geschlossen werden _muss_.
und das mit den 100 % ist FUD mein Freund …
Ein Serverchild kann maximal einen Request pro Zeit bearbeiten. wird er gezwungen, einen Prozess dauerhaft aufrechtzuerhalten, ist seine Kapazität zu 100% belastet. Ich weiß nicht, was daran „FUD“ sein soll; wobei mir diese Abkürzung auch nicht geläufig ist. Vielleicht stellt es eine Bestätigung dar?
Ein Chat über HTTP ist kriminell.
in deinen Augen, also hör auf deine Subjektive Meinung mit den
Objektiven Fakten zu mischen …
Tut mir leid, ich bin mir nun mal der Konsequenzen solchen Tuns bewusst. Wenn’s Dir besser gefällt: Ein Chat über HTTP ist schädlich.
ich geb zu Ideal ist das
ganze per HTTP nicht, aber machbar …
Unter eklatanter Missachtung (international gültiger und nutzungsverpflichtender) technischer Vorgaben sowie einer übermäßig hohen Belastung sämtlicher beteiligten Systeme. Wie gesagt: Man kann auch mit einem Auto fliegen. Ob die Versicherung anschließend zahlt, ist fraglich.
Cheatah
Hi,
DAS sog. Protokol gibt es nicht …
hm? Ich rede vom Hypertext Transfer Protocol, also HTTP. Du
hast Recht, es gibt davon mehrere Versionen; aber in Hinsicht
auf die grundlegende Arbeitsweise unterscheiden sie sich
nicht. HTTP ist in allen bisherigen Versionen zustands- und
verbindungslos.
nein … du redest von IRC …
es gibt für ein Problem mehrere Lösung
Ja. Dabei sind gewöhnlich .gute und schlechte.
jup 
… das ist eine weitere Differenzierung
(du erinnerst mich ein wenig an einen
verblendeten Fanatiker)Tatsächlich. Vielleicht habe ich aber auch nur ein
Fachverständnis entwickelt, das Dir noch fehlt? Klar kann man
einen Drehstuhl auf einen Tisch stellen, um darüber die
Glühbirne tauschen zu können (der Kumpel hält den Stuhl ja
fest) - ein Sicherheitsexperte wird aber bei sowas vor Schreck
leichenblass. Und das nicht, weil er fanatisch ist.
ich denke ich hab genügend Fachverständnis, vielleicht reden wir auch nur aneinander vorbei ?
Nicht falsch. HTTP ist für einen Chat nicht geeignet.
das sagst du … (und das ist dann wohl deine subjektive
Meinung PUNKT)Nein, es ist eine objektive Beurteilung der Fakten. Ein Chat
benötigt bestehende Verbindungen, HTTP basiert auf _nicht_
bestehenden Verbindungen. Daran ist nicht das geringste
subjektiv.
stop stop stop: das ist deine Definiton eines chattest, es sind mehrere Formen möglich, die nur von der Definition abhängt
ich kann ebenso gut ein eigenes
Chat-Protokol schreiben, so wie es mir passt …Klar, kannst Du gerne tun; IRC ist nicht das einzig denkbare
Protokoll für einen Chat, es ist nur meine Empfehlung. Ein
neues oder anderes Protokoll ändert aber nichts daran, dass
HTTP sich nicht für einen Chat eignet.
du hast es aber so dargestellt, als wäre IRC das einzig denkbare … dagegen bin ich Sturmgelaufen … deine Kritik an HTTP kann ich nachvollziehen und verstehe sie auch, allerdings sind auch mit diesem verkrüpelten ansatz Lösungen denkbar (was diese Lösunge schlussendlich sind -> gut oder schlecht bleibt aber objektiv dem Benutzer überlassen … (das hat mit der technik dahinter nichts zu tun)
und solange du
das nicht einsiehst solltest du vielleicht mal über die RFCsDiesen Satz habe ich leider nicht verstanden.
wir verstehen uns
Sie funktionieren nicht besser, als eine Zahnoperation unter
Lachgas.also gut ? … für viele jedenfalls gut genug
Ja; und diese vielen wissen leider nicht, was sie damit für
Schaden anrichten.
von was für einem Schaden redest du ? z.B. giga.de hat eigene Server … wo entsteht da schaden und für wen ?
Deren Programmierer werden leider allzu selten in die
Verantwortung gezogen. Seriöse Provider untersagen den Einsatz
von HTTP-Chats.Programmierer, Verantwortung ?? hast du einen knall ?
Nein, wieso?
Wer sollte von wem für was zur Verantwortung gezogen werden unter welchem Grund ? (legitimieren lässt sich das ganze nicht …)
ich seh nicht ein wo „schaden“ entstehen soll (ausser vielleicht bei privaten, deren domains du hostest und die deinen server mit solchem Scheiss in die Knie zwingen, aber da ist es ja kein Problem diesen in den Arsch zu treten, ansonsten zahlen die Kunden ja für ihre Server und es ist dir ja wohl freigestellt, was du damit machst (für den Traffic zahlst du ja auch … und selbst wenn du darüber einen Stream machst der sinnlose primzahlen in der Welt verteilt: WAS hat das deinen Provider zu interessieren solange du seine Systeme damit nicht in die Knie bringst ? (was AFAIK bei webchats nicht gegeben ist)
ich darf mir doch einen eigenen Chat coden OHNE das du auch
nur etwas dazu zu sagen hast …Natürlich kann ich Dir das nicht verbieten, und das will ich
auch gar nicht. Wenn Du den Chat nur schreibst, hab ich da
nichts gegen. Willst Du ihn aber _einsetzen_, stellst Du eine
Gefahr für das Internet und die darin befindlichen Systeme
dar.
hä ???
ich wiederhol meine Feststellung: vielleicht solltest du dich mal ein wenig über TCP/IP und co. informieren … ein Webchat kann man wohl kaum als gefahr bezeichnen, da er im wesentlichen (z.B. mit Flush) einen Stream darstellt … sind deshalt die Internet-Radios auch eine Gefahr fürs Internet ?
Untermauere doch bitte diese Behauptung mit technischen Fakten …
Der Gesetzgeber verbietet nicht den Kauf oder Besitz eines
Radarwarnsystems, es ist im Prinzip ja auch nichts schlimmes
daran. Der _Einsatz_ eines solchen jedoch ist strafbar. Was
bedauerlich ist ist, dass der Gesetzgeber in netzbezüglichen
Dingen noch ziemlich unausgereifte Sprüche gefällt hat; im
Grunde genommen wirst Du erst dann verantwortlich gemacht,
wenn Du messbaren Schaden angerichtet hast. Der Betrieb von
schadenverursachenden Systemen wird nicht unterbunden, darum
gibt es auch noch solche Chats, wie Du sie hier verteidigst.
wie gesagt: bring diese Diskussion bitte auf ein technisches Niveau und Versuch nicht mit Vergleichen zu argumentieren
Als Programmiersprachen für einen Webchat eignen sich
*Die* *Programmiersprache* *ist* *egal,* solange das Protokoll
nicht geeignet ist.lies meinen Satz … (da steht GROSS Webchat …)
Lies meinen Satz, da steht auch Webchat, versteckt im Begriff
„Protokoll“. Ein Chat über HTTP ist _unabhängig von der
Programmiersprache_, ähm, suboptimal.
…
aber es gibt 100’000 andere
möglichkeiten OHNE IRC einen vernünftigen Chat aufzubauen
(z.B. per Applet oder Flash und nem eigenen chat-server ?)Herrje - das _ist_ IRC! Nur weil ein Applet oder was immer
über HTTP angefordert wurde heißt das noch lange nicht, dass
es anschließend auch weiterhin über HTTP kommuniziert. Es gibt
genügend Chat-Applets (ein Flash hierzu habe ich noch nicht
gesehen, das heißt aber nichts), die über IRC und „einen
eigenen Chat-Server“ arbeiten.
lies meinen Satz … ich kann auch BC (das Bernie Chat Protokoll) erfinden, wir unterhalten uns z.B. über ICMP-Packete und das Subset ist total anders als bei IRC … Punkt!
Lies und begreife RFC 2616 und sag das noch mal. […]
tut mir leid, ich hab genug zu lesen … und schreib mir
nicht vor, was ich zu tun habe …Sorry, bisher ging ich davon aus, dass Du daran interessiert
bist zu verstehen. Wenn Du nicht die Quellen lesen willst, in
denen meine Äußerungen bestätigt werden, muss ich meine
diesbezügliche Meinung wohl anpassen.
ich hab schon verschiedene eigene Kommunikationsprotokolle implementiert … und IRC ist nichts anderes als ein Kommunikationsprotokoll, und ich kann ganz einfach mein eigenes Implementieren … das siehst du doch wohl ein ?
scheint eh ein wenig dein
Problem zu sein … (NUR du hast ja recht …)Nein, nur Du liegst falsch. Die Fakten sind hier sehr einfach;
es ist nicht mal eine Meinungsfrage. Wenn Du nicht begreifen
möchtest, dass Dein Kenntnisstand über HTTP noch ausbaufähig
ist, dann wirf mir doch bitte nicht vor, engstirnig zu sein.
Ich bin mir einfach nur einer Tatsache bewusst, die Du noch
nicht verinnerlicht hast.
Mein Kenntissstand über HTTP ist ausreichend, aber vielleicht solltest du dir vielleicht mal deinen Kenntisstand über TCP/IP auffrischen … (und einsehen das DNS, HTTP und letzlich auch IRC nichts anderes ist als ein Subset auf dieses grundlegende Protokoll, das man beliebig austauschen kann … ich kann auch meine eigene DNS-Implementierung schreibe und ein Programm das diese dann auch so braucht)
was anderes ist dann eine BESTEHENDE Verbindung, als eine die
nicht geschlossen wird ??Eine, die nicht geschlossen werden _muss_.
und das mit den 100 % ist FUD mein Freund …
Ein Serverchild kann maximal einen Request pro Zeit
bearbeiten. wird er gezwungen, einen Prozess dauerhaft
aufrechtzuerhalten, ist seine Kapazität zu 100% belastet. Ich
weiß nicht, was daran „FUD“ sein soll; wobei mir diese
Abkürzung auch nicht geläufig ist. Vielleicht stellt es eine
Bestätigung darf
das child mag besetzt sein, der CPU ist es nicht und das ist entscheident für die Performance-bremse … schon mal nen Apache konfiguriert ?
Ein Chat über HTTP ist kriminell.
in deinen Augen, also hör auf deine Subjektive Meinung mit den
Objektiven Fakten zu mischen …Tut mir leid, ich bin mir nun mal der Konsequenzen solchen
Tuns bewusst. Wenn’s Dir besser gefällt: Ein Chat über HTTP
ist schädlich.
für wen ??
argumentier endlich technisch!
ich geb zu Ideal ist das
ganze per HTTP nicht, aber machbar …Unter eklatanter Missachtung (international gültiger und
nutzungsverpflichtender) technischer Vorgaben sowie einer
übermäßig hohen Belastung sämtlicher beteiligten Systeme. Wie
gesagt: Man kann auch mit einem Auto fliegen. Ob die
Versicherung anschließend zahlt, ist fraglich.
blabla ?
wo bleibt deine technische Argumentation, wer wird belastet ?
Cheatah
Berni
Hi,
nein … du redest von IRC …
ich rede von beidem 
Genauer gesagt rede ich davon, dass man niemals einen Chat auf HTTP-Basis einsetzen soll, sondern auf z.B. IRC-Basis. Hauptsächlich geht es mir aber um HTTP.
ich denke ich hab genügend Fachverständnis, vielleicht reden
wir auch nur aneinander vorbei ?
Das ist nicht auszuschließen - siehe unten.
Ein Chat
benötigt bestehende Verbindungen, HTTP basiert auf _nicht_
bestehenden Verbindungen. Daran ist nicht das geringste
subjektiv.stop stop stop: das ist deine Definiton eines chattest,
„Chat-Test“?
Also, ein Chat ist in jedem Fall eine Echtzeit-Kommunikation. Für Echtzeit ist es notwendig, die Verbindung offenzuhalten, damit a) der Server in beliebig kurzer Zeit von Aktionen erfährt, und b) diese in ebenso kurzer Zeit an alle übrigen Beteiligten weiterverteilt werden können.
HTTP scheidet für so etwas aus, da es nur mit der Brechstange dazu missbraucht werden kann, die Verbindung (zumindest zeitweise, bis irgendein System einen Timeout erkennt und die Leitung kappt) offen zu halten, was wie erwähnt keinem der betroffenen Systeme gut tut, am allerwenigsten dem Server.
Der „Workaround“, ständig eine Ressource neu anzufordern, ist ebenfalls nicht das Gelbe vom Ei, sondern eher das Grüne vom faulen solchen. Im Sekundentakt (o.ä.) werden neue Verbindungen geöffnet, um vom Server etwas anzufordern, was notwendigerweise von einer Programmlogik bearbeitet werden muss, was a) mehr Serverchildren beansprucht als nötig wäre und b) dem Rechner ziemlich an die Eingeweide geht (insbesondere wenn nicht „zufällig“ ein Servermodul vorliegt, welches es ermöglicht, nicht nur den Programminterpreter im Speicher zu halten, sondern auch die Daten - was aufgrund der Prozessverteilung auf n Worker ein ziemlich hochgesetztes Ziel ist).
Hinzu kommt, dass insbesondere Proxies bei solchen Dingen nicht übel ins Schwitzen geraten, um keine veralteten Versionen auszuliefern und _trotzdem_ nicht in die Knie gehen, was anderen Benutzern dieses Systems sicher auch nicht gefallen würde. Von dem Aufwand, den jeder Aufbau einer Connection mit sich führt, und dem eigentlichen Roundtrip will ich erst gar nicht reden. Mit Echtzeit hat das dann eh höchstens noch periphär zu tun, was sich auch in zeitlichen Überschneidungen unterschiedlicher Requests niederschlägt.
Klar, es sind Lösungen möglich; wenn auch mehr leidlich. Diejenigen, die sie gefunden und umgesetzt haben, haben aber entweder keine Ahnung davon, was sie damit eigentlich anrichten, oder aber keine Skrupel.
es sind mehrere Formen möglich, die nur von der Definition
abhängt
Hier weiß ich nicht, was Du meinst. Redest Du von der Definition eines Chats?
du hast es aber so dargestellt, als wäre IRC das einzig
denkbare …
Wenn Du das so verstanden hast, tut es mir leid. IRC ist meiner Meinung nach für einen Chat ideal, deswegen habe ich es empfohlen.
dagegen bin ich Sturmgelaufen …
Und ich bin dagegen sturmgelaufen, dass HTTP eine Alternative darstellt… denn so habe ich Dich verstanden Wir scheinen also wirklich aneinander vorbeigeredet zu haben.
deine Kritik an
HTTP kann ich nachvollziehen und verstehe sie auch, allerdings
sind auch mit diesem verkrüpelten ansatz Lösungen denkbar (was
diese Lösunge schlussendlich sind -> gut oder schlecht
bleibt aber objektiv dem Benutzer überlassen … (das hat mit
der technik dahinter nichts zu tun)
Nun ja, die Technik leidet ggf. an der Beurteilung des Benutzers, der die Konsequenzen gewöhnlich nicht hinreichend gut einschätzen kann. An der leidenden Technik leiden wiederum die Benutzer… Wie sagte TV Kaiser immer? Ein Teufelskreis
von was für einem Schaden redest du ? z.B. giga.de hat eigene
Server … wo entsteht da schaden und für wen ?
Wie gesagt, es gibt noch mehr Systeme zwischen Server und Client. Router, Proxies, DNS-Server…
Wer sollte von wem für was zur Verantwortung gezogen werden
unter welchem Grund ?
Das „von wem“ kann ich Dir auch nicht sagen - es gibt keine Internetpolizei (o.ä.), die die Interessen aller User vertritt; und „alle User“ sind genau die, die ggf. unter einem HTTP-Chat leiden. Das „wer“ hingegen ist leicht: jeder, der einen HTTP-Chat einsetzt. Dieser mag die Verantwortung z.B. an den Entwickler desselben weiterreichen; ich will hier keine Gesetzesgrundlage schaffen (das würde meine Kompetenzen auch geringfügig überschreiten *g*).
(legitimieren lässt sich das ganze nicht …)
Ein HTTP-Chat? Nein, wirklich nicht
ich wiederhol meine Feststellung: vielleicht solltest du dich
mal ein wenig über TCP/IP und co. informieren … ein Webchat
kann man wohl kaum als gefahr bezeichnen, da er im
wesentlichen (z.B. mit Flush) einen Stream darstellt … sind
deshalt die Internet-Radios auch eine Gefahr fürs Internet ?
Möchtest Du hierzu ehrlich meine Meinung hören? Nun, mit Internet-Radios habe ich mich noch nicht besonders beschäftigt. Soweit ich aber weiß, ist dazu eine serverseitige Erweiterung von Nöten, um das ganze dort zu ermöglichen. Aus Clientsicht ist das dann (soweit ich es verstehe) nur noch eine große Ressource - und dagegen ist wirklich nichts einzuwenden. Ein kontinuierlicher Strom ist genau das, was HTTP beherrscht. Was es _nicht_ beherrschen soll ist a) ein ständig unterbrochener Strom („ab und zu wird auch mal was geliefert“, sowas ist ein sicheres Zeichen für eine defekte Verbindung und wird von Automaten ggf. auch so behandelt), und b) Interaktion innerhalb einer Verbindung, wie es bei einem Chat nun mal nötig ist. Wenn der Server beginnt, Daten zu senden, hat der Client den Mund zu halten.
Untermauere doch bitte diese Behauptung mit technischen Fakten
…
Ich hoffe, die obigen Erklärungen entsprechen Deiner Bitte
wie gesagt: bring diese Diskussion bitte auf ein technisches
Niveau und Versuch nicht mit Vergleichen zu argumentieren
Mit Vergleichen will ich nicht argumentieren, sondern verdeutlichen. Eine Analogie hilft oft, das Verständnis auf ein abstrakteres Niveau zu heben.
(z.B. per Applet oder Flash und nem eigenen chat-server ?)
Herrje - das _ist_ IRC! […]
lies meinen Satz … ich kann auch BC (das Bernie Chat
Protokoll) erfinden, wir unterhalten uns z.B. über
ICMP-Packete und das Subset ist total anders als bei IRC …
Punkt!
*seufz* Das, was es diesbezüglich gibt, verwendet in aller Regel IRC. Zumindest verwendet es kein HTTP
Mein Kenntissstand über HTTP ist ausreichend, aber vielleicht
solltest du dir vielleicht mal deinen Kenntisstand über TCP/IP
auffrischen … (und einsehen das DNS, HTTP und letzlich auch
IRC nichts anderes ist als ein Subset auf dieses grundlegende
Protokoll, das man beliebig austauschen kann … ich kann auch
meine eigene DNS-Implementierung schreibe und ein Programm das
diese dann auch so braucht)
Ich glaube Dir sogar, dass Du das kannst. Allerdings wirst Du zugeben, dass hierzu jeweils nicht nur eigene Server vonnöten sind, sondern auch eigene Clients. Wenn man aber den Browser verwendet (himself, also nicht irgendeine darin gestartete Applikation), ist man in der Wahl der Protokolle eingeschränkt… und üblicherweise kommen IRC und andere chattaugliche Protokolle darin nicht vor.
das child mag besetzt sein, der CPU ist es nicht und das ist
entscheident für die Performance-bremse … schon mal nen
Apache konfiguriert ?
Ja, und genau deswegen muss ich Dir widersprechen. Die CPU ist weiß Gott nicht das einzige, was für die Performance entscheidend ist.
argumentier endlich technisch!
Mir ist nicht bewusst, dass ich bisher nicht technisch argumentiert hätte.
ich geb zu Ideal ist das
ganze per HTTP nicht, aber machbar …Unter eklatanter Missachtung (international gültiger und
nutzungsverpflichtender) technischer Vorgaben sowie einer
übermäßig hohen Belastung sämtlicher beteiligten Systeme. Wie
gesagt: Man kann auch mit einem Auto fliegen. Ob die
Versicherung anschließend zahlt, ist fraglich.blabla ?
Argumentiere bitte technisch
Cheatah
Hi,
nein … du redest von IRC …
ich rede von beidem
man niemals einen Chat auf HTTP-Basis einsetzen soll, sondern
auf z.B. IRC-Basis. Hauptsächlich geht es mir aber um HTTP.
ok, IRC-Basis ist für dich Client-Server und mit einer Definition von versch. Requests
ziemlich allgemein (kannst du fast auf jedes bidirektionale Protokoll anwenden)
ich denke ich hab genügend Fachverständnis, vielleicht reden
wir auch nur aneinander vorbei ?Das ist nicht auszuschließen - siehe unten.
ich glaub definitf ja
Ein Chat
benötigt bestehende Verbindungen, HTTP basiert auf _nicht_
bestehenden Verbindungen. Daran ist nicht das geringste
subjektiv.stop stop stop: das ist deine Definiton eines chattest,
„Chat-Test“?
verschreiber
(hab in der letzten woche nicht zu viel Schlaf gekommen … mein Physik-Studium nimmt mich zur zeit ziemlich mit [> 60 h pro woche]
Also, ein Chat ist in jedem Fall eine Echtzeit-Kommunikation.
Für Echtzeit ist es notwendig, die Verbindung offenzuhalten,
damit a) der Server in beliebig kurzer Zeit von Aktionen
erfährt, und b) diese in ebenso kurzer Zeit an alle übrigen
Beteiligten weiterverteilt werden können.HTTP scheidet für so etwas aus, da es nur mit der Brechstange
dazu missbraucht werden kann, die Verbindung (zumindest
zeitweise, bis irgendein System einen Timeout erkennt und die
Leitung kappt) offen zu halten, was wie erwähnt keinem der
betroffenen Systeme gut tut, am allerwenigsten dem Server.Der „Workaround“, ständig eine Ressource neu anzufordern, ist
ebenfalls nicht das Gelbe vom Ei, sondern eher das Grüne vom
faulen solchen. Im Sekundentakt (o.ä.) werden neue
Verbindungen geöffnet, um vom Server etwas anzufordern, was
notwendigerweise von einer Programmlogik bearbeitet werden
muss, was a) mehr Serverchildren beansprucht als nötig wäre
und b) dem Rechner ziemlich an die Eingeweide geht
(insbesondere wenn nicht „zufällig“ ein Servermodul vorliegt,
welches es ermöglicht, nicht nur den Programminterpreter im
Speicher zu halten, sondern auch die Daten - was aufgrund der
Prozessverteilung auf n Worker ein ziemlich hochgesetztes Ziel
ist).
stimmt … problematisch ist es vorallem wenn du den Server für verschiedene Anforderungen konfiguriert hast … (z.B. max request per child ist tödlich)
Hinzu kommt, dass insbesondere Proxies bei solchen Dingen
nicht übel ins Schwitzen geraten, um keine veralteten
Versionen auszuliefern und _trotzdem_ nicht in die Knie gehen,
was anderen Benutzern dieses Systems sicher auch nicht
gefallen würde. Von dem Aufwand, den jeder Aufbau einer
Connection mit sich führt, und dem eigentlichen Roundtrip will
ich erst gar nicht reden. Mit Echtzeit hat das dann eh
höchstens noch periphär zu tun, was sich auch in zeitlichen
Überschneidungen unterschiedlicher Requests niederschlägt.
Proxis sind recht stabile gebilde … bei häufigen requests wird nichts mehr heftig gecached
Klar, es sind Lösungen möglich; wenn auch mehr leidlich.
Diejenigen, die sie gefunden und umgesetzt haben, haben aber
entweder keine Ahnung davon, was sie damit eigentlich
anrichten, oder aber keine Skrupel.
der Fall den du beschreibst wird aber nie jemanden konkret treffen: angenommen du hast einen proxy an einer Schule und 10 leute chatten über einen solchen „Müll“ … für den proxy ist das ganze eine zu ertragende last … ich kann durchaus den Makel einer solchen implementation sehen, aber die Probleme die dadurch entstehen sind mir Fremd: den http-chat gibt es schon seit jahren, und er „funktioniert“ auch schon seit jahren suboptimal, aber dem Internet hat es nicht geschadet [es steht jedenfalls noch]
es sind mehrere Formen möglich, die nur von der Definition
abhängtHier weiß ich nicht, was Du meinst. Redest Du von der
Definition eines Chats?
jo freudscher verschreiber
du hast es aber so dargestellt, als wäre IRC das einzig
denkbare …Wenn Du das so verstanden hast, tut es mir leid. IRC ist
meiner Meinung nach für einen Chat ideal, deswegen habe ich es
empfohlen.
ok
dagegen bin ich Sturmgelaufen …
Und ich bin dagegen sturmgelaufen, dass HTTP eine Alternative
darstellt… denn so habe ich Dich verstanden
also wirklich aneinander vorbeigeredet zu haben.
dann verstehen wir uns ja … HTTP mag eine Alternative sein (aber sie hinkt gewaltigt einem IRC hinternach, das ist mir auch klar)
deine Kritik an
HTTP kann ich nachvollziehen und verstehe sie auch, allerdings
sind auch mit diesem verkrüpelten ansatz Lösungen denkbar (was
diese Lösunge schlussendlich sind -> gut oder schlecht
bleibt aber objektiv dem Benutzer überlassen … (das hat mit
der technik dahinter nichts zu tun)Nun ja, die Technik leidet ggf. an der Beurteilung des
Benutzers, der die Konsequenzen gewöhnlich nicht hinreichend
gut einschätzen kann. An der leidenden Technik leiden wiederum
die Benutzer… Wie sagte TV Kaiser immer? Ein Teufelskreis-)
hehe
von was für einem Schaden redest du ? z.B. giga.de hat eigene
Server … wo entsteht da schaden und für wen ?Wie gesagt, es gibt noch mehr Systeme zwischen Server und
Client. Router, Proxies, DNS-Server…
das ist mir auch klar, aber letzthin verursacht ein chat nur Traffic … router interessieren sich nicht für chat-protokolle, der dns-server wird auch nicht übermässige belastet (die Verbindung wird ja nicht geschlossen …
Die wichtigste Infrastrukur, die du beschrieben hast, ist der Router … und der transportiert wirklich nur packete … offene verbindungen auf packet-ebene gibt es nicht, das ist eine „Illusion“ des oberen Layers
Wer sollte von wem für was zur Verantwortung gezogen werden
unter welchem Grund ?Das „von wem“ kann ich Dir auch nicht sagen - es gibt keine
Internetpolizei (o.ä.), die die Interessen aller User
vertritt; und „alle User“ sind genau die, die ggf. unter einem
HTTP-Chat leiden. Das „wer“ hingegen ist leicht: jeder, der
einen HTTP-Chat einsetzt. Dieser mag die Verantwortung z.B. an
den Entwickler desselben weiterreichen; ich will hier keine
Gesetzesgrundlage schaffen (das würde meine Kompetenzen auch
geringfügig überschreiten *g*).
ich leide nicht unter HTTP-Chats
(legitimieren lässt sich das ganze nicht …)
Ein HTTP-Chat? Nein, wirklich nicht
hehe, das nenn ich jemanden worte in den Mund legen
ich wiederhol meine Feststellung: vielleicht solltest du dich
mal ein wenig über TCP/IP und co. informieren … ein Webchat
kann man wohl kaum als gefahr bezeichnen, da er im
wesentlichen (z.B. mit Flush) einen Stream darstellt … sind
deshalt die Internet-Radios auch eine Gefahr fürs Internet ?Möchtest Du hierzu ehrlich meine Meinung hören?
Internet-Radios habe ich mich noch nicht besonders
beschäftigt. Soweit ich aber weiß, ist dazu eine serverseitige
Erweiterung von Nöten, um das ganze dort zu ermöglichen. Aus
Clientsicht ist das dann (soweit ich es verstehe) nur noch
eine große Ressource - und dagegen ist wirklich nichts
einzuwenden. Ein kontinuierlicher Strom ist genau das, was
HTTP beherrscht. Was es _nicht_ beherrschen soll ist a) ein
ständig unterbrochener Strom („ab und zu wird auch mal was
geliefert“, sowas ist ein sicheres Zeichen für eine defekte
Verbindung und wird von Automaten ggf. auch so behandelt), und
wie gesagt: kein Problem
packete unterscheiden sich nicht, ein Strom-Packet ist das gleiche wie ein einzelnes … einzig der Server lässt ein child dafür abstellen, der dann schnellstmöglich den (ja wieder erwarteten) request handeln kann … ein internet-radio und flush haben einiges gemeinsam: du darfst dir das ganze nicht als kontinuirliche verbindung vorstellen, das ist ein falsches bild … der Client wartet einfach (das braucht keine bandbreite, da kein Packetverkehr stattfindet) auf ein weiteres packet, das aber noch nicht gekommen ist … das ist wie eine html-site, die noch nicht fertig geladen ist
ich geb dir ein beispiel:
http://www.n.ethz.ch/student/floriabe/download/scree…
das ist der link zu nem screen-shot von einem HTTP-Chat, der mit flush arbeitet
oben im bild siehst du ein Programm (iptraf heisst das ganze) und das zeigt die offenen Verbindungen zwischen meinem laptop und dem internet an und die anzahl Packete, die darüber laufen … der erste eintrag ist ein stream (per flush), der hat vier packete erhalten und der darunter vom unteren frame des chats, das geladen worden ist, aber dessen verbindung noch offen ist … ein http-server schliesst die verbindung nicht sofort nach dem übermitteln der daten, man kann ein timeout angeben … dort wird bald closed stehen … der stream verursacht aber keine Packete solange der server nichts schickt, somit ist keine Belastung von Routern vorhanden einverstanden ?
b) Interaktion innerhalb einer Verbindung, wie es bei einem
Chat nun mal nötig ist. Wenn der Server beginnt, Daten zu
senden, hat der Client den Mund zu halten.
…
Untermauere doch bitte diese Behauptung mit technischen Fakten
…Ich hoffe, die obigen Erklärungen entsprechen Deiner Bitte
wie gesagt: bring diese Diskussion bitte auf ein technisches
Niveau und Versuch nicht mit Vergleichen zu argumentierenMit Vergleichen will ich nicht argumentieren, sondern
verdeutlichen. Eine Analogie hilft oft, das Verständnis auf
ein abstrakteres Niveau zu heben.
wir sind doch alles Abstrakte-Säue und stehen auf sowas
(z.B. per Applet oder Flash und nem eigenen chat-server ?)
Herrje - das _ist_ IRC! […]
lies meinen Satz … ich kann auch BC (das Bernie Chat
Protokoll) erfinden, wir unterhalten uns z.B. über
ICMP-Packete und das Subset ist total anders als bei IRC …
Punkt!*seufz* Das, was es diesbezüglich gibt, verwendet in aller
Regel IRC. Zumindest verwendet es kein HTTP
ok einverstanden
Mein Kenntissstand über HTTP ist ausreichend, aber vielleicht
solltest du dir vielleicht mal deinen Kenntisstand über TCP/IP
auffrischen … (und einsehen das DNS, HTTP und letzlich auch
IRC nichts anderes ist als ein Subset auf dieses grundlegende
Protokoll, das man beliebig austauschen kann … ich kann auch
meine eigene DNS-Implementierung schreibe und ein Programm das
diese dann auch so braucht)Ich glaube Dir sogar, dass Du das kannst. Allerdings wirst Du
zugeben, dass hierzu jeweils nicht nur eigene Server vonnöten
sind, sondern auch eigene Clients. Wenn man aber den Browser
verwendet (himself, also nicht irgendeine darin gestartete
Applikation), ist man in der Wahl der Protokolle
eingeschränkt… und üblicherweise kommen IRC und andere
chattaugliche Protokolle darin nicht vor.
jup, oder du passt die api dazu an
das child mag besetzt sein, der CPU ist es nicht und das ist
entscheident für die Performance-bremse … schon mal nen
Apache konfiguriert ?Ja, und genau deswegen muss ich Dir widersprechen. Die CPU ist
weiß Gott nicht das einzige, was für die Performance
entscheidend ist.
hmm, ok ram … aber das ist meist vernachlässigbar
ich geb zu Ideal ist das
ganze per HTTP nicht, aber machbar …Unter eklatanter Missachtung (international gültiger und
nutzungsverpflichtender) technischer Vorgaben sowie einer
übermäßig hohen Belastung sämtlicher beteiligten Systeme. Wie
gesagt: Man kann auch mit einem Auto fliegen. Ob die
Versicherung anschließend zahlt, ist fraglich.blabla ?
Argumentiere bitte technisch
blabla
Cheatah
gruss
berni
Ich möchte Euch danken, für die rege Diskusion. Nie hätte ich gedacht, daß ein Chat solche Probleme auslösen kann. Daß ein paar Textnachrichten einen Server in die Knie zwingen kann, hätte ich nie vermutet. Ich hätte ehr gedacht, daß die vielen Bilder im Internet viel größere Probleme darstellen.
Jetzt werde ich mich erst einmal informieren, wie IRC funktioniert. Vielleicht werde ich eines Tages in der Lage sein, einen Chat zu verstehen oder gar nachzuempfinden.
Vielen Dank!
Guido
