fsockopen via udp oder http
Rolf
- php
0 Mega0 Sven Rautenberg
0 Rouven
Hallo,
es soll innerhalb eines Scriptes ein kurzer String (z.b. '1.0.0.1')
an ein entferntes Script gesendet werden, ohne dass das Script auf
die Antwort warten muss.
Wäre dafür UDP besser geeignet als HTTP oder wie seht ihr das ?
m.b.G. Rolf
Wäre dafür UDP besser geeignet als HTTP oder wie seht ihr das ?
Einfacher ist HTTP. Und zwar, weil du dann nur eine URL mit dem Text als Parameter aufrufen musst.
Moin!
Wäre dafür UDP besser geeignet als HTTP oder wie seht ihr das ?
Einfacher ist HTTP. Und zwar, weil du dann nur eine URL mit dem Text als Parameter aufrufen musst.
Nein.
UDP und HTTP sind nicht miteinander vergleichbar. UDP ist ein Protokoll auf der mittleren Ebene, und HTTP ist ein Protokoll auf der höchsten Ebene.
HTTP verwendet TCP. TCP ist mit UDP vergleichbar, weil es auf derselben Ebene ansetzt.
HTTP ist auch deshalb komplexer und alles andere als "einfacher", weil es ein sehr komplexes Protokoll geworden ist, und man sich mit ziemlich vielen Sonderfällen auseinandersetzen muß.
Hingegen einfach per UDP ein Datenpaket an ein Ziel zu senden ist simpel und einfach, wenn das Ziel damit was anzufangen weiß. Ich gehe mal davon aus, dass ein entsprechender Empfänger dort konstruiert werden wird.
- Sven Rautenberg
Hi!
HTTP verwendet TCP.
HTTP kann ein _beliebiges_ Transport-Protokoll nutzen - im Internet ist es TCP, ja!
HTTP ist auch deshalb komplexer
HTTP ist komplexer als TCP?
Wie meinst du das?
und alles andere als "einfacher", weil es ein sehr komplexes Protokoll geworden ist, und man sich mit ziemlich vielen Sonderfällen auseinandersetzen muß.
Also im Vergleich zu TCP sehe ich HTTP eher als Protokoll-Leichtgewicht.
Habe ich Dich missverstanden?
off:PP
Moin!
HTTP verwendet TCP.
HTTP kann ein _beliebiges_ Transport-Protokoll nutzen - im Internet ist es TCP, ja!
Das schweift aber in genau die Feinheiten ab, die man eigentlich gerade vermeiden will...
HTTP ist auch deshalb komplexer
HTTP ist komplexer als TCP?
Erheblich.
und alles andere als "einfacher", weil es ein sehr komplexes Protokoll geworden ist, und man sich mit ziemlich vielen Sonderfällen auseinandersetzen muß.
Also im Vergleich zu TCP sehe ich HTTP eher als Protokoll-Leichtgewicht.
HTTP ist ein komplexes Protokoll, es sieht nur einfach aus, weil das meiste davon Klartext ist.
Aber an die Formatierung dieses Klartextes und insbesondere an das Verstehen einer eventuellen Antwort werden sehr hohe Ansprüche gestellt. So hohe Ansprüche, dass es teilweise noch heute HTTP-Clients gibt, die das nicht alles 100% hinkriegen.
Wenn es nur darum geht, irgendeinem zweiten System einen Statuspieps durchzugeben, von dem nichts abhängt und er deshalb auch gern verloren gehen darf, dann ist UDP das Netzprotokoll der Wahl, und die Nutzlast bastelt man sich am Schlauesten so einfach, wie man es benötigt: Klartext bietet sich irgendwie an.
Mit HTTP wäre der notwendige Overhead und insbesondere die zwangsläufig erfolgende zweifache Antwort (einmal auf TCP-Ebene, einmal auf HTTP-Ebene) doch eher hinderlich.
- Sven Rautenberg
Hi!
HTTP verwendet TCP.
HTTP kann ein _beliebiges_ Transport-Protokoll nutzen - im Internet ist es TCP, ja!
Das schweift aber in genau die Feinheiten ab, die man eigentlich gerade vermeiden will...
Wer ist man?
HTTP ist auch deshalb komplexer
HTTP ist komplexer als TCP?
Erheblich.
NACK - ich habe nicht behauptet, das Anwendungsprotokoll HTTP sei simpel.
und alles andere als "einfacher", weil es ein sehr komplexes Protokoll geworden ist, und man sich mit ziemlich vielen Sonderfällen auseinandersetzen muß.
Das betreitet niemand.
Also im Vergleich zu TCP sehe ich HTTP eher als Protokoll-Leichtgewicht.
HTTP ist ein komplexes Protokoll, es sieht nur einfach aus, weil das meiste davon Klartext ist.
Ja.
Aber an die Formatierung dieses Klartextes und insbesondere an das Verstehen einer eventuellen Antwort werden sehr hohe Ansprüche gestellt. So hohe Ansprüche, dass es teilweise noch heute HTTP-Clients gibt, die das nicht alles 100% hinkriegen.
Auch richtig.
Wenn es nur darum geht, irgendeinem zweiten System einen Statuspieps durchzugeben, von dem nichts abhängt und er deshalb auch gern verloren gehen darf, dann ist UDP das Netzprotokoll der Wahl, und die Nutzlast bastelt man sich am Schlauesten so einfach, wie man es benötigt: Klartext bietet sich irgendwie an.
Natürlich ist UDP wesentlich 'schlanker' als TCP, aber was hat das mit der Aussage zu tun, HTTP sei wesentlich komplexer als TCP?
Mit HTTP wäre der notwendige Overhead und insbesondere die zwangsläufig erfolgende zweifache Antwort (einmal auf TCP-Ebene, einmal auf HTTP-Ebene) doch eher hinderlich.
Den Zusammenhang vermag ich nicht zu sehen.
Vielleicht verstehen wir den Begriff 'komplex' an dieser Stelle unterschiedlich.
Vermittle doch bitte mal jemandem die Funktionsweise von TCP und von HTTP - wofür wirst du mehr Sätze benötigen?
off:PP
Moin!
Natürlich ist UDP wesentlich 'schlanker' als TCP, aber was hat das mit der Aussage zu tun, HTTP sei wesentlich komplexer als TCP?
Wenn ich mit jemandem via UDP oder TCP sprechen will, mache ich fsockopen() und bin fertig.
Wenn ich mit jemand HTTP sprechen will, muß ich mich zusätzlich noch um tausend andere Dinge kümmern.
Resultat: HTTP ist komplexer als TCP oder UDP. Weil etwas, das etwas anderes benutzt, als zusammengesetztes System komplexer ist, als jedes einzelne.
Vermittle doch bitte mal jemandem die Funktionsweise von TCP und von HTTP - wofür wirst du mehr Sätze benötigen?
Wenn ich alles schreiben muss, damit derjenige hinterher eine funktionierende Implementierung schreiben kann: Für HTTP.
- Sven Rautenberg
Hi Sven!
Natürlich ist UDP wesentlich 'schlanker' als TCP, aber was hat das mit der Aussage zu tun, HTTP sei wesentlich komplexer als TCP?
Wenn ich mit jemandem via UDP oder TCP sprechen will, mache ich fsockopen() und bin fertig.
Ach, so kompliziert?
Wenn ich per HTTP kommunizieren möchte, öffne ich meinen Lieblings-HTTP-User-Agent aka 'Browser'!
Wenn ich mit jemand HTTP sprechen will, muß ich mich zusätzlich noch um tausend andere Dinge kümmern.
Welche denn?
IMHO sollte sich ein Protokoll der Anwendungsschicht darauf verlassen (können müssen), dass die darunter liegenden Schichten korrekt arbeiten.
Resultat: HTTP ist komplexer als TCP oder UDP.
Deine Schlußfolgerung finde ich an dieser Stelle etwas vorschnell!
Weil etwas, das etwas anderes benutzt, als zusammengesetztes System komplexer ist, als jedes einzelne.
Ja, aber Du vergleichst das Gesamtsystem mit einem Teil dessen.
Vermittle doch bitte mal jemandem die Funktionsweise von TCP und von HTTP - wofür wirst du mehr Sätze benötigen?
Wenn ich alles schreiben muss, damit derjenige hinterher eine funktionierende Implementierung schreiben kann: Für HTTP.
Ich meinte den Umfang von TCP vs. den von HTTP
und _nicht_ (z.B.):
TCP vs: HTTP
TCP
IP
Network
Das war ja wohl klar, oder?
off:PP
Sorry Sven,
wenn einem bei der Mittagsruhe etwas durch den Kopf schiesst,
sollte man sowas eigentlich nicht sofort breittreten ... :-(
Mein Fehler!
Was ich wirklich meinte, war:
Welcher Aufruf belastet das sendende Script mehr:
Also, vielen Dank für Eure Bemühungen! Werde in Zukunft erst eine Tasse
Kaffee trinken und das Herzhäuschen aufsuchen, bevor ich hier rumposte.
m.b.G. Rolf
Moin!
Welcher Aufruf belastet das sendende Script mehr:
- ein fsockopen('http://host.de', 80, $errno, $errstr);
- oder fsockopen('udp://host.de', 13, $errno, $errstr);
Logischerweise der zweite, da der erste eine illegale Adresse enthält und daher direkt zu einer Fehlermeldung führt.
ABER:
Da der Apache mit UDP-Requests nicht umgehen kann, ist es eine hohle Frage!
Sowieso. Jedenfalls, wenn der Apache als Empfangsstation dienen soll.
Es gäbe noch diverse Alternativmöglichkeiten - welche sinnvoll nutzbar ist, hängt von den näheren Umständen ab.
- Sven Rautenberg
Hello,
Wäre dafür UDP besser geeignet als HTTP oder wie seht ihr das ?
es sollte nicht außer Acht gelassen werden, dass UDP-Pakete spurlos verschwinden dürfen...
MfG
Rouven