nicht angemeldetIst da eine Störung gemeldet oder liegts an der Zeitumstellung? Auf denen ihrer Seite steht nichts. Bitte mal um Hinweises.
Alle drei sind per NTP erreichbar.
Alle drei sind per NTP erreichbar.
Ich brauche mindestens einen Monat bis ich NTP verstanden hab 😉
Alle drei sind per NTP erreichbar.
Ich brauche mindestens einen Monat bis ich NTP verstanden hab 😉
Man muss ja nicht alles machen was NTP so bietet. Wenn man nur die aktuelle Zeit vom Zeitserver braucht, reicht das hier.
Tipp: Wireshark erklärt das Protokoll. MFG
Hallo ntp,
Man muss ja nicht alles machen was NTP so bietet. Wenn man nur die aktuelle Zeit vom Zeitserver braucht, reicht das hier.
Man könnte auch Net::NTP verwenden.
… oder es gleich komplett richtig machen und den NTP-Daemon des OS nutzen.
Das ist definitiv empfehlenswert, denn bei zu vielen Anfragen auf öffentliche NTP-Server wird man schlicht geblockt.
LG,
CK
oder es gleich komplett richtig machen und den NTP-Daemon des OS nutzen.
Das ist auch wiedermal eine Empfehlung die sowohl unbegründet als auch unsinnig ist. Zumal man einen NTP-Daemon auf dem eigenen OS gar nicht braucht. MFG
Zumal man einen NTP-Daemon auf dem eigenen OS gar nicht braucht.
Das stimmt insoweit, als dass den Job des lokalen NTP-Servers in hunderttausenden (wenn nicht millionen) deutscher Haushalte die Fritzbox erledigt. Andere Boxen dito. In anderen Netzen wird man ebenso einen eigenen NTP-Server haben und den Clients via DHCP verpetzen.
Es gibt auch NTP-Clients. Die Vorteile des NTP-Protokolls überwiegen den Mehrverbrauch von 40 Bytes gegenüber dem von Dir nachgebauten TIME-Protokoll. Es sei denn Du betreibst Dein TCP/IP auf der Grundlage eines physikalischen Datentransports per Brieftaube und gießt die Nachricht in Blei.
Da sind wir auch bei der von Dir selbst aufgeworfenen Frage nach TCP vers. UDP. Der TCP-Handshake ist "teuer": Wenn Du schon gegen jeden guten Rat einen TIME-Server bauen willst - warum hängst Du den nicht mittels xinetd oder ähnlichem als einfaches echo an Port 37 UDP?
Moin,
Einen Daytime Server mit IO::Socket zu bauen ist keine Hexerei. Darüber hab ich vor über 20 Jahren sogar mal einen Artikel geschrieben. Aber wie schon mehrfach festgestellt: Ich brauche weder Daytime noch NTP noch einen dedizierten Server. Ich habe mein Framework!
MFG
Aloha ;)
Ich brauche weder Daytime noch NTP noch einen dedizierten Server. Ich habe mein Framework!
Stimmt ja.
Funktioniert etwa so wie bei Asterix.
Dein Framework ist der Zaubertrank, der in der Story quasi alles kann und dessen tatsächliche Existenz und Funktionalität von außen betrachtet nicht beweisbar ist - man muss halt dran glauben. In diesem Bild wärst du dann vermutlich das gallische Dorf, das den Zaubertrank exklusiv und nur für sich, dort aber für alles, verwendet, und die Welt um dich rum, die dir nicht so recht glaubt, sind die römischen Legionäre, die als Besatzung in den befestigten Lagern Babaorum, Aquarium, Laudanum und Kleinbonum liegen. Und ja, unser Leben ist wahrlich nicht leicht!
Grüße,
RIDER
Es kommt immer darauf an die Idee zu verstehen: Webservices an beliebige URLs zu binden. Kann das Dein Famework auch!? MFG
Aloha ;)
Kann das Dein Famework auch!?
Ich hab ja keins. Und leider ist es mir auch noch nicht gelungen, einen ent-sprechenden Druiden zu kidnappen, der mir dann die relevanten Geheimnisse verrät um eins nachzubauen.
Grüße,
RIDER
Man muss ja nicht alles machen was NTP so bietet. Wenn man nur die aktuelle Zeit vom Zeitserver braucht, reicht das hier.
Man könnte auch Net::NTP verwenden.
Mir ist noch nie ein CPAN Modul untergekommen was so dermaßen schlecht dokumentiert ist! Und schon der Beispielcode liefert haufenweise Fehlermeldungen.
Keine gute Empfehlung!
Hallo pl,
Man könnte auch Net::NTP verwenden.
Mir ist noch nie ein CPAN Modul untergekommen was so dermaßen schlecht dokumentiert ist! Und schon der Beispielcode liefert haufenweise Fehlermeldungen.
Keine gute Empfehlung!
Die Doku beschränkt sich leider auf das Notwendigste und der Beispielcode funktioniert nicht wirklich, das stimmt. Grundsätzlich funktioniert die bereitgestellte Methode get_ntp_response() aber.
Gruß
Patrick
Ich habe hier noch 2 Screenshots angehängt. Wie ich schonmal schrieb, Wireshark erklärt das Protokoll sehr anschaulich.
Grundsätzlich funktioniert die bereitgestellte Methode get_ntp_response() aber.
Es ist nicht dokumentiert was genau diese Funktion sendet. Und die 48 Bytes für den Request kann ich mir auch selbst zusammenstellen, da weiß ich wenigstens was ich sende und wie ich die Response auszuwerten habe.
Auch sehr schön geschrieben: NTP in C
Man muss sich einfach nur selber mal damit befassen. MFG
Hallo pl,
Ich habe hier noch 2 Screenshots angehängt. Wie ich schonmal schrieb, Wireshark erklärt das Protokoll sehr anschaulich.
Ja, nur glaube ich nicht, dass jemand, der einfach mal schnell einen NTP-Server abfragen will, Interesse daran hat, zunächst das Protokoll zu analysieren und dann die Byte-Folgen zu zerlegen.
Grundsätzlich funktioniert die bereitgestellte Methode get_ntp_response() aber.
Es ist nicht dokumentiert was genau diese Funktion sendet.
Wireshark? Quellcode lesen?
Ohne groß von NTP Ahnung zu haben: Was soll da versendet werden, von dem du nicht möchtest, dass es versendet wird?
Weiterhin: Ich kann weder in der Doku der Python-, noch bei der Ruby-Implementierung etwas finden, was beschreibt, was genau verschickt wird. Diese Information scheint also nicht besonders wichtig zu sein.
Gruß
Patrick
Ja sicher doch, Wireshark zeigt schon was gesendet und empfangen wird. Nur ist es eben nicht der Sinn und Zweck einer POD und noch dazu von einem CPAN Modul, daß man erst einen Networkanalyzer anwerfen muss um zu sehen was das Modul macht!
Hallo pl,
Ja sicher doch, Wireshark zeigt schon was gesendet und empfangen wird. Nur ist es eben nicht der Sinn und Zweck einer POD und noch dazu von einem CPAN Modul, daß man erst einen Networkanalyzer anwerfen muss um zu sehen was das Modul macht!
Noch mal: Was soll da versendet werden, von dem du oder der Rest der Welt nicht möchte, dass es versendet wird?
Gruß
Patrick
Weiterhin: Ich kann weder in der Doku der Python-, noch bei der Ruby-Implementierung etwas finden, was beschreibt, was genau verschickt wird. Diese Information scheint also nicht besonders wichtig zu sein.
Die Info ist schon wichtig. Aber sowas steht eher in einer Norm als in einer Programmdokumentation. Sie ist also, und nur das ist wichtig, verfügbar.
Eine solche wäre: RFC 5905
Hallo ursus,
Weiterhin: Ich kann weder in der Doku der Python-, noch bei der Ruby-Implementierung etwas finden, was beschreibt, was genau verschickt wird. Diese Information scheint also nicht besonders wichtig zu sein.
Die Info ist schon wichtig. Aber sowas steht eher in einer Norm als in einer Programmdokumentation. Sie ist also, und nur das ist wichtig, verfügbar.
Ja, da hast du recht, ich habe mich falsch ausgedrückt. Ich meinte eher, dass es dann wohl selbstverständlich ist und man deswegen drauf verzichten kann.
Gruß
Patrick
Besonders witzig finde ich das da in der Net::NTP POD
Camping_RIDER
Tabellenkalk
MudGuard
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Reference Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Origin Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receive Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Transmit Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field 1 (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field 2 (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| dgst (128) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
was der Author ohne jeden Kommentar aus dem RFC kopiert hat. Kannst ja mal versuchen, aus diesem Schema obenstehend abzuleiten wie die 48 Bytes einer NTP Message für den Request zusammengesetzt werden sollen.
Oder auch nur den Zusammenhang zum Modul herzustellen!
MFG
Hallo pl,
OK, einigen wir uns darauf, dass die Doku misslungen ist und man das wesentliche nicht sofort erkennen kann.
Jedoch halte ich nach wie vor eine genaue Auflistung, wo welche Werte eingesetzt werden müssen, in diesem Fall für weniger wichtig. Dazu gibt es bessere Quellen und ich hätte an der Stelle des Autors auch kein Interesse, das noch mal zu erklären.
Gruß
Patrick
Dazu gibt es bessere Quellen und ich hätte an der Stelle des Autors auch kein Interesse, das noch mal zu erklären.
Dann macht es ja erst recht keinen Sinn dieses Schema was schon per RFC schwer verständlich ist, kommentarlos in eine POD zu kopieren. Zumal die ganze API Beschreibung sehr zu wünschen übrig lässt. Im Sinne von CPAN ist das nicht. Und leider auch kein Einzelfall. MFG
traceroute to ptbtime1.ptb.de (192.53.103.108), 30 hops max, 60 byte packets
1 81.28.224.1 (81.28.224.1) 7.749 ms 7.679 ms 7.643 ms
2 ge0-0-603.core.ber2.de.scaleuptech.com (93.92.131.69) 0.091 ms 0.104 ms 0.075 ms
3 4ge2-2-11.core.ber2.de.scaleuptech.com (93.92.131.66) 0.163 ms 0.181 ms 0.198 ms
4 dfn.bcix.de (193.178.185.42) 1.086 ms 1.151 ms 1.123 ms
5 cr-han2-be7.x-win.dfn.de (188.1.144.137) 5.456 ms 5.920 ms 5.938 ms
(das war der letzte pingbare "Hop".)
traceroute to ptbtime2.ptb.de (192.53.103.104), 30 hops max, 60 byte packets
1 81.28.224.1 (81.28.224.1) 1.015 ms 1.001 ms 0.961 ms
2 ge0-0-603.core.ber2.de.scaleuptech.com (93.92.131.69) 0.078 ms 0.092 ms 0.108 ms
3 4ge2-2-11.core.ber2.de.scaleuptech.com (93.92.131.66) 0.133 ms 0.147 ms 0.213 ms
4 dfn.bcix.de (193.178.185.42) 0.828 ms 0.839 ms 1.197 ms
5 cr-han2-be7.x-win.dfn.de (188.1.144.137) 5.494 ms 5.553 ms 5.570 ms
(das war der letzte pingbare "Hop" im "Deutschen Forschungsnetz")
traceroute to ptbtime3.ptb.de (192.53.103.103), 30 hops max, 60 byte packets
1 81.28.224.1 (81.28.224.1) 1.267 ms 1.193 ms 1.211 ms
2 ge0-0-603.core.ber2.de.scaleuptech.com (93.92.131.69) 0.074 ms 0.087 ms 0.098 ms
3 4ge2-2-11.core.ber2.de.scaleuptech.com (93.92.131.66) 0.298 ms 0.313 ms 0.273 ms
4 dfn.bcix.de (193.178.185.42) 1.177 ms 1.145 ms 1.141 ms
5 cr-han2-be7.x-win.dfn.de (188.1.144.137) 5.957 ms 6.039 ms 5.933 ms
Vermutung: Nicht etwa ein Bug sondern ein Bagger ist schuld.
Aber:
31 Mar 15:53:56 ntpdate[7531]: adjust time server 192.53.103.108 offset 0.001207 sec
31 Mar 15:54:18 ntpdate[7534]: adjust time server 192.53.103.104 offset -0.000599 sec
31 Mar 15:54:30 ntpdate[7536]: adjust time server 192.53.103.103 offset 0.000180 sec
Die obige Vermutung ist widerlegt. Die wollen nur keine Pings.
Wie es in der Vergangenheit mit ICMP aussah kann Dir gar nicht sagen. Die genaue Zeit hab ich bisher immer auf Port 37 abgeholt, vor ein paar Tagen ging das noch. MFG
Die genaue Zeit hab ich bisher immer auf Port 37 abgeholt, vor ein paar Tagen ging das noch.
Das time Protocol ist schon lange durch NTP quasi obsolet geworden; bin überrascht, dass sie das so lange angeboten haben.
Die genaue Zeit hab ich bisher immer auf Port 37 abgeholt, vor ein paar Tagen ging das noch.
Das time Protocol ist schon lange durch NTP quasi obsolet geworden; bin überrascht, dass sie das so lange angeboten haben.
Kurzer Anruf, Service eingestellt. Hol ich mir die Zeit eben vonda 😉
Hol ich mir die Zeit eben vonda 😉
wget -d http://rolfrost.de/?time=1
---request begin---
GET /?time=1 HTTP/1.1
User-Agent: Wget/1.19.4 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: rolfrost.de
Connection: Keep-Alive
---request end---
HTTP-Anforderung gesendet, auf Antwort wird gewartet …
---response begin---
HTTP/1.1 200 OK
Date: Tue, 02 Apr 2019 17:17:37 GMT
Server: Apache
Content-Language: de
x-param: title=FWNG%2C%20modern%20MVC%20Web%20Application%20Framework%20in%20Perl%20und%20in%20C;descr=Modern%20Web%20Framework%20Next%20Generation%20in%20Perl%20und%20in%20C%20programmiert
x-class: HTMLfile
Expires: Thu, 11 Jul 2019 00:00:00 GMT
Content-Length: 10
Last-Modified: Tue, 02 Apr 2019 00:00:00 GMT
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=UTF-8
→ grep --invert-match "${unwesentliches}" →
Date: Tue, 02 Apr 2019 17:17:37 GMT
Expires: Thu, 11 Jul 2019 00:00:00 GMT
Last-Modified: Tue, 02 Apr 2019 00:00:00 GMT
Das ist alles andere als eine gute Idee.
Die Zeit stimmt schon. Aber: Dein wget cached die Response!
Btw.: NTP sendet serverseitig gegenüber Daytime nicht 4 sondern 48 Bytes. Wobei für NTP auch ein Request mit 48 Bytes geschickt werden muss. Also von wegen Overhead!
Hallo pl,
Die Zeit stimmt schon. Aber: Dein wget cached die Response!
wget cached nicht.
LG,
CK
Zugegeben, der Lastmodified Header ist an der Stelle unsinnig, aber man muss ihn ja nicht nutzen.
Nimm einen Client der nicht cached:
use LWP::Simple;
print scalar localtime get "http://rolfrost.de/?time=1";
und schon funktioniert das wie gewünscht. MFG
Hallo pl,
Nimm einen Client der nicht cached:
Ich wiederhole mich nur ungern, aber wget cached nicht.
➜ ckruse@Pug ~ % curl --head https://forum.selfhtml.org/assets/selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700bac79021e8579.svg
HTTP/1.1 200 OK
Server: nginx/1.14.0
Date: Wed, 03 Apr 2019 06:53:55 GMT
Content-Type: image/svg+xml
Content-Length: 33784
Last-Modified: Fri, 10 Mar 2017 19:02:30 GMT
Connection: keep-alive
Vary: Accept-Encoding
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Cache-Control: public
Accept-Ranges: bytes
➜ ckruse@Pug ~ % wget https://forum.selfhtml.org/assets/selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700bac79021e8579.svg
--2019-04-03 08:53:57-- https://forum.selfhtml.org/assets/selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700bac79021e8579.svg
Resolving forum.selfhtml.org (forum.selfhtml.org)... 89.238.65.20
Connecting to forum.selfhtml.org (forum.selfhtml.org)|89.238.65.20|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33784 (33K) [image/svg+xml]
Saving to: ‘selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700bac79021e8579.svg’
selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700b 100%[===================================================================>] 32.99K --.-KB/s in 0.02s
2019-04-03 08:53:57 (1.96 MB/s) - ‘selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700bac79021e8579.svg’ saved [33784/33784]
➜ ckruse@Pug ~ % wget https://forum.selfhtml.org/assets/selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700bac79021e8579.svg
--2019-04-03 08:54:00-- https://forum.selfhtml.org/assets/selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700bac79021e8579.svg
Resolving forum.selfhtml.org (forum.selfhtml.org)... 89.238.65.20
Connecting to forum.selfhtml.org (forum.selfhtml.org)|89.238.65.20|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33784 (33K) [image/svg+xml]
Saving to: ‘selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700bac79021e8579.svg.1’
selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700b 100%[===================================================================>] 32.99K --.-KB/s in 0.02s
2019-04-03 08:54:00 (1.91 MB/s) - ‘selfhtml-forum-d673516635a6d8384b74d9126219623c06d3c325719e52c5700bac79021e8579.svg.1’ saved [33784/33784]
➜ ckruse@Pug ~ %
Beachte die Caching-Header im curl --head und die Tatsache, dass wget beide Male die Datei herunterlädt.
Nochmal zum mitschreiben: wget cached nicht.
LG,
CK
wget cached nicht.
wget selbst nicht. Aber (nicht nur) wget schickt die Abfrage z.B. an den Proxy der in ${http_proxy} steht. Das Environment wiederum hat seine Quelle beim dhcpcd... In dem Sinne verstehe ich nicht, warum PL herumdiskutiert statt einfach weniger, dafür aber brauchbare bzw. korrekte header zu senden, ggf. die Zeit wenigstens mittels eines "gemeinsamen Geheimnisses" zu signieren wenn er schon kein https nehmen will.
Da ich gerade dhcp erwähnte: Ein korrekter lokaler / besonderer NTP-Server kann den Clients im Netz via DHCP zugewiesen werden. Ich weiß nicht warum PL par tout eine eigene Lösung fahren will.
Hallo ursus,
wget selbst nicht. Aber (nicht nur) wget schickt die Abfrage z.B. an den Proxy der in
${http_proxy}steht. Das Environment wiederum hat seine Quelle beim dhcpcd...
Top Gelegenheit, sich in den Fuß zu schiessen 😉
Ich weiß nicht warum PL par tout eine eigene Lösung fahren will.
Das zu verstehen habe ich schon lange aufgegeben. Vieles von dem, was er tut, ist technisch ausgesprochen bedenklich.
LG,
CK
Falsch! Warum sollte ich mit Dir diskutieren!? Wie Du mit Lastmodified umzugehen hast musst Du schon selber lernen. Und wenn Du über einen Proxy gehst ist das schließlich Dein Problem und nicht meins.
Falsch! Warum sollte ich mit Dir diskutieren!
Weil ich in diesem Forum einiges gelernt und durch das Erarbeiten von Lösungen sehr unterschiedlicher und oft aus genau solchen "historisch gewachsenen" Eigen-/Insellösungen nebst Nebeneffekten resultierender Probleme meiner Kunden inzwischen eine Menge über Server und Netzwerke weiß, also gute Ratschläge für Dich habe?
Nein. Deine dortige Ausführung "Lastmodified Header ist an der Stelle unsinnig, aber man muss ihn ja nicht nutzen." ist falsch. Richtig wäre: Man darf ihn nicht senden. Und, wenn Du das Cachen unterbinden willst, niemals einen Expires-Header, der auf ein Datum in 3 Monaten verweist.
Moin,
Also ich habe mir das nochmal überlegt. Beide Header, sowohl Lastmodified als auch Expires haben ihre Berechtigung und Gültigkeit.
MFG
Zugegeben, der Lastmodified Header ist an der Stelle unsinnig, aber man muss ihn ja nicht nutzen.
Nimm einen Client der nicht cached:
use LWP::Simple; print scalar localtime get "http://rolfrost.de/?time=1";und schon funktioniert das wie gewünscht. MFG
PS: Wer das mit dem Browser ausprobieren möchte, schalte den Cache aus mit [shift]+[reload]. Es ist nur eine Demo.
PS: Wer das mit dem Browser ausprobieren möchte, schalte den Cache aus
Für das Senden korrekter Header ist der Server verantwortlich. Niemals darf man erwarten, dass der Client oder gar die Infrastruktur (Proxys!) die gesendeten Header missachtet.
Es ist nur eine Demo.
Wie war das doch gleich?
Hol ich mir die Zeit eben vonda 😉
Da steht nichts von Demo. Da steht, Du holst Dir die Zeit von diesem Server mit dieser Methode und also den falschen HTTP-Headern.
Und ich verstehe nicht, warum Du derart widersinniges tust. Denn den schon früher mal von Dir genannten Vorteil, dass TIME weniger Daten sende als NTP und dass Du nun selbst nur weniger Bytes senden und empfangen willst führst Du durch die Nutzung des HTTP-Protokolls recht gründlich ad absurdum. NTP funktioniert und Du machst Dir vorliegend nur Stress.
Ok, extra für Dich.
Zunächst die Anwendung:
use LWP::Simple;
print scalar localtime unpack "N", get "http://rolfrost.de/cgi-bin/nph-time.cgi";
Es ist ein Non Parsed Header Script. Somit ist der Overhead minimal.
#!/usr/bin/perl
binmode STDOUT;
print "HTTP/1.0 200 OK\r\n\r\n".pack("N", time);
Wie Du sehen kannst, wird gar kein Responseheader gesendet. Der Client bekommt lediglich die HTTP Version und den Status mitgeteilt. Die Response selbst, also der Messagebody hat eine Länge von genau 4 Bytes. Das ist ein Big Endian, die Anzahl der Sekunden seit 1.1.1970
Dekodieren kannst Du das auch mit PHP/unpack. MFG
#!/usr/bin/perl binmode STDOUT; print "HTTP/1.0 200 OK\r\n\r\n".pack("N", time);
Wie Du sehen kannst, wird gar kein Responseheader gesendet. Der Client bekommt lediglich die HTTP Version und den Status mitgeteilt.
Oh Mann! So kannst Du doch nicht diskutieren. Die fachgerechte Ermittlung ergab ganz eindeutig folgende Header:
---response begin---
HTTP/1.1 200 OK
Date: Tue, 02 Apr 2019 17:17:37 GMT
Server: Apache
Content-Language: de
x-param: title=FWNG%2C%20modern%20MVC%20Web%20Application%20Framework%20in%20Perl%20und%20in%20C;descr=Modern%20Web%20Framework%20Next%20Generation%20in%20Perl%20und%20in%20C%20programmiert
x-class: HTMLfile
Expires: Thu, 11 Jul 2019 00:00:00 GMT
Content-Length: 10
Last-Modified: Tue, 02 Apr 2019 00:00:00 GMT
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=UTF-8
Es ist demnach der von Dir konfigurierte Apache-Webserver, der den übergebenen Response-Header mit unsinnigen, zum Teil grob falschen Werten ergänzt, teils überschreibt und die Antwort weiter gibt.
Und Dir sollte auch endlich einmal auffallen, dass Du das die Zeit zweimal gesendet hast:
pack("N", time);Date: Tue, 02 Apr 2019 17:17:37 GMTGenau so geht "overhead".
Du hast im Skript versteckt, eine neue URL angegeben, die alte sendet einen "502er": Bad gateway
http://rolfrost.de/cgi-bin/nph-time.cgi
Das von mir geschriebene gilt auch dann wenn Du das Zeug inzwischen kommentarlos bis klammheimlich geändert hast. Denn einerseits folgst Du den Ratschlägen, behauptest aber die würden nichts taugen. So kannst Du doch nicht ernsthaft diskutieren.
http://rolfrost.de/cgi-bin/nph-time.cgi ist ein Non Parsed Header Script. Das wird, wie der Name schon sagt, vom Webserver nicht geparst sondern nur durchgereicht. Somit ist es ausgeschlossen, daß der Webserver spontan irgendwelche Header dazutut. Also auch keinen Date Header sondern gar keine Header.
Und dieses NPH Script ist auch nur ein Beispiel dafür, wie man einen Zeitstempel effizient auch per HTTP übertragen kann. HTTP/1.0 200 OK + Leerzeile + Zeitstempel sind zusammen 23 Bytes und damit ist die Datenmenge halb so groß wie die 48 Bytes einer NTP Response.
Ein Mehr-Overhead liegt einzig im Protokoll TCP vs. UDP begründet. Deine Headerdiskussion ist unsinnig. MFG
Warum fällt es Dir so unendlich schwer, einfach mal etwas zu schreiben wie "Ok. Die Implementierung war schlecht, habe das jetzt anders gemacht"?
Deine Headerdiskussion ist unsinnig.
Im Hinblick auf Deine Änderungen war meine Headerdiskussion sehr produktiv.
Moin pl,
gerade eben getestet unter Umgehung von Caches aber mit Proxy:
601 Bytes sind transferiert worden, dabei …
… 571 Byte HTTP-Header:
HTTP/1.1 200 OK
Date: Mon, 01 Apr 2019 14:32:14 GMT
Server: Apache
Content-Language: en
x-param: title=FWNG%2C%20modern%20MVC%20Web%20Application%20Framework%20in%20Perl%20und%20in%20C;descr=Modern%20Web%20Framework%20Next%20Generation%20in%20Perl%20und%20in%20C%20programmiert
x-class: HTMLfile
Last-Modified: Mon, 01 Apr 2019 00:00:00 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 30
Content-Type: text/html; charset=UTF-8
Age: 165782
Connection: keep-alive
Expires: Wed, 10 Jul 2019 00:00:00 GMT
Via: 1.1 akamai (ACE 5.10.3/5.10.3)
… und der Payload ist interessanter Weise kürzer als die angegebenen 30 Byte:
1554129135
Dazu kommen dann – ohne Cache – auch noch der zweite Round-Trip mit 487 Byte für das Favicon, wenn man das im Browser aufruft.
Wie war das – NTP hat verschwenderische 48 Byte bei jedem Aufruf?
Deine NPH-Variante kommt immer noch auf 152 Byte, also dem Dreifachen von NTP. Dein Zeitstempel sind 4 Byte binär und die HTTP-Header
HTTP/1.1 200 OK
Date: Wed, 03 Apr 2019 12:41:03 GMT
Age: 0
Transfer-Encoding: chunked
Connection: close
Via: 1.1 akamai (ACE 5.10.3/5.10.3)
Viele Grüße
Robert
gerade eben getestet unter Umgehung von Caches aber mit Proxy:
1554129135
Kann gar nicht sein. Prüf mal Deinen Proxy, der cached eine Ressource die es gar nicht mehr gibt!
Deine NPH-Variante kommt immer noch auf 152 Byte, also dem Dreifachen von NTP. Dein Zeitstempel sind 4 Byte binär und die HTTP-Header
HTTP/1.1 200 OK Date: Wed, 03 Apr 2019 12:41:03 GMT Age: 0 Transfer-Encoding: chunked Connection: close Via: 1.1 akamai (ACE 5.10.3/5.10.3)
Auch falsch. Diese Header generiert Dein Proxy. MFG
PS: Richtig prüfen:
use IO::Socket;
my $so = IO::Socket::INET->new("rolfrost.de:80") or die $@;
$so->print("GET /cgi-bin/nph-time.cgi HTTP/1.0\nHost: rolfrost.de\n\n");
print while <$so>;
Und das ist die Response
HTTP/1.0 200 OK
\¤®
gerade eben getestet unter Umgehung von Caches aber mit Proxy:
1554129135Kann gar nicht sein. Prüf mal Deinen Proxy, der cached eine Ressource die es gar nicht mehr gibt!
Es war DEIN Server, der gestern, am 03.04.2019, behauptet hat, dass die gelieferten Daten bis 11. Juli 2019 00:00:00 GMT gültig seien:
Expires: Thu, 11 Jul 2019 00:00:00 GMT
Ein Revalidate hattes Du durch Deine Header nicht verlangt, Proxys nicht ausgeschlossen. Du solltest Robert B. also loben — denn sein Proxy funktioniert vortrefflich.
PS: Richtig prüfen:
Nein! Richtig hinweisen: "Ich habe da einiges verändert und bin, um durch meine frühere Angabe des Expires-Datums entstehende Effekte durch Caches und Proxys zu vermeiden, auf eine neue URL umgezogen."
Allein schon der Gedanke, zeitkritische Daten übern Proxy zu schleifen ist irgendwie dämlich. MFG
Moin,
welchen Sinn im Allgemeinen ein Proxy hat und warum ich vielleicht hinter einem sitze, den ich nicht unbedingt „einfach mal ausschalten kann“, brauche ich hier wohl nicht zu erläutern. Es gibt Proxies, sie sind erlaubt und sie werden verwendet. Deal with it – vor allem, wenn sie mit dem eigentlichen Problem nur periphär zu tun haben.
Viele Grüße
Robert
Moin,
welchen Sinn im Allgemeinen ein Proxy hat und warum ich vielleicht hinter einem sitze, den ich nicht unbedingt „einfach mal ausschalten kann“, brauche ich hier wohl nicht zu erläutern.
Ne, musst nicht. Hab Dich schon verstanden!
Ne, musst nicht.
Ich habe für Dich einen teuflisch gemein bösen Rat wie man eine solche Situation rettet und „König“ bleibt:
Es ist (nach dem ersten Mal) ganz einfach zu sagen oder zu schreiben: „Du hast Recht. Ich hab ${irgend einen Scheiß} übersehen.“ Und schon hat man die ärgerliche und sonst ausufernde Diskussion mit geringstem Ansehensschaden vom Hals. Im Gegenteil halten alle einen für einen tollen Hecht, der sowas locker zugeben kann.
Sollte man natürlich nur (aber immer dann) machen, wenn's denn stimmt.
Es gibt 3 Dinge die einen Entwickler auszeichnen:
Diese 3 Dinge begleiten mich seit meiner frühesten Jugend. Und am meisten beneidet werde ich wegen Punkt 3! MFG
3. Beharrlichkeit
Und am meisten beneidet werde ich wegen Punkt 3!
Bezüglich der Beharrlichkeit schenken wir uns nichts. Deshalb lege ich Dir meinen Ratschlag nochmals an Herz. Und bitte Dich zu prüfen, was noch Beharrlichkeit oder was schon Starrsinn sein könnte.
Moin,
Meine Entscheidung für die HTTP Lösung ist sowohl zweckmäßig als auch praktischer Natur. Zweckmäßig deswegen weil es nur ein paar Zeilen sind, mein Framework diesbezüglich zu erweitern. Praktisch weil es keines zusätzlichen Scripts bedarf, ich nutze ganz einfach nur das was ich ohnehin schon habe: Mein Framework an dem ich jeden Tag meine Freude habe. Und damit wären wir wieder bei den 3 Eigenschaften
MFG
Hallo pl,
nach diesen Gesichtspunkten wäre es deutlich praktischer und zweckmäßiger, die deinem Betriebssystem beiliegenden Methoden zur Zeit-Synchronisation via NTP zu nutzen. Sowohl Windows als auch Linux als auch macOS können das seit Jahrzehnten von Haus aus.
Und einen NTP-Server hat fast jeder bereits mit seiner Fritz!Box oder ähnlichem im Haus. Ansonsten bieten die OSe auch die Möglichkeit, öffentliche NTP-Server zu verwenden.
Aufwand: vielleicht 5 Minuten.
LG,
CK
hi CK
nach diesen Gesichtspunkten wäre es deutlich praktischer und zweckmäßiger, die deinem Betriebssystem beiliegenden Methoden zur Zeit-Synchronisation via NTP zu nutzen.
Nein. Meine Anforderung heißt: Gelegentlich die Uhr aufm Desktop zu stellen wobei es auf ein paar Sekunden mehr oder weniger nicht ankommt. Dafür brauche ich kein NTP, dafür hab ich mein Framework.
MFG
Hallo pl,
Dafür brauche ich kein NTP, dafür hab ich mein Framework.
You do you, man, das steht dir frei.
Und mir steht es frei das für dumm und unhandlich zu halten. 🤷♂️
LG,
CK
Hallo pl,
Nein. Meine Anforderung heißt: Gelegentlich die Uhr aufm Desktop zu stellen wobei es auf ein paar Sekunden mehr oder weniger nicht ankommt. Dafür brauche ich kein NTP, dafür hab ich mein Framework.
Wie CK schon sagte, jedes moderne Betriebssystem synchronisiert die Systemuhr regelmäßig automatisch und zuverlässig, ohne dass man irgendwas machen muss. Und da, wo man nachhelfen muss, weil man nicht direkt ins Internet kommt, nehme ich einen NTP-Server vor Ort. Und danach funktioniert es auch.
Gruß
Patrick
… und der Payload ist interessanter Weise kürzer als die angegebenen 30 Byte:
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 30
Ja. Der Proxy war das. Der hat, hier widersinnig (weil mit größerem Ergebnis), den Content "gepackt". Schau mal, falls Du den verwaltest, in dessen Manual nach ob man das Packen unterhalb von 1k verbieten kann: Bringt dann faktisch nichts.
… und der Payload ist interessanter Weise kürzer als die angegebenen 30 Byte:
Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 30Ja. Der Proxy war das. Der hat, hier widersinnig (weil mit größerem Ergebnis), den Content "gepackt". Schau mal, falls Du den verwaltest, in dessen Manual nach ob man das Packen unterhalb von 1k verbieten kann: Bringt dann faktisch nichts.
Deswegen ja ein NPH Script. Ein solches übern Proxy zu requesten ist völliger Blödsinn. Im Übrigen gibt es zum NTP praktisch gar keinen Unterschied in Sachen Performance. Natürlich auch nur wenn man einen minimalen HTTP Client darauf ansetzt:
my $so = IO::Socket::INET->new("rolfrost.de:80") or die $@;
$so->print("GET /cgi-bin/nph-time.cgi HTTP/1.0\nHost: rolfrost.de\n\n");
my $res = do{ local $/ = undef; <$so>};
my $t = [unpack "C19N", $res]; # Genau 23 Bytes hat die Response
my $gmt = [gmtime($t->[19])]; # Zeitstempel in den letzten 4 Bytes
und auch hier siehst Du den Vorteil von NPH: Die gesamte Response lässt sich damit bytegenau zusammenstellen und damit auch bytegenau dekodieren. Eben weil der Webserver die ungeparst durchreicht. Ein Proxy hingegen weiß ja gar nicht daß es ein NPH Script ist, der parst das und hängt eigene Header an.
MFG
PS: Bei 4 Bytes im Message Body gibt es nichts zu packen. Das ist schon gepackt. Im Übrigen wird HTTP/1.0 verwendet. Da gibt es gar keine Komprimierung die kam erst mit HTTP/1.1
Deswegen ja ein NPH Script. Ein solches übern Proxy zu requesten ist völliger Blödsinn.
Tja. So halt halt jeder was davon. Kurz nachdem Du weg bist stelle ich dann auf Grund von ${Disfunction} Dein nicht genormtes und in unerwarteter Weise reagierendes Zeug auf NTP um, weil Du stur behauptest, dass es sehr wohl funktioniert.
Es gibt halt immer mehrere Möglichkeiten für das was man tut. Aber bevor man etwas tut muss man sich erst einmal mit der Materie befassen. NTP ist ziemlich umfangreich und genau deswegen kann man es auch auf verschiedene Art und Weise nutzen. Aber egal ob man über NTP den BIAS zu seiner eigenen Systemzeit bestimmen oder einfach nur einen Zeitserver befragen will, stets läuft es darauf hinaus, einen Request an den Server zu senden und die Response zu empfangen und zu verarbeiten.
Genau das ist der Unterschied zum Protokoll Daytime: Bei NTP kann man die eigene Systemzeit an den Server senden, man muss es aber nicht. Was man jedoch tun muss: Man muss bei NTP einen Request senden, bei Daytime muss man das nicht. Und genau deswegen funktioniert NTP vom Prinzip her genauso wie HTTP: Es ist ein Request/Response Dialog!
Und genau wie bei HTTP muss in NTP der Request einen ganz bestimmten Satzbau haben und genauso hat auch jede Response eine ganz bestimmten Aufbau. Und wenn man das einmal verstanden hat kommt man dahin, zu prüfen, inwieweit man damit seine eigenen Anforderungen abdecken kann.
Für meine Anforderungen, die darin bestehen ab und zu per Mausklick eine Desktop Uhr zu stellen wobei es auf ein paar Sekunden mehr oder weniger gar nicht ankommt, kann ich natürlich auch NTP verwenden aber letztendlich brauche ich von den 48 Bytes der Response nur 4, welche das sind hab ich hier mal aufgeschrieben. Schlicht und einfach kann ich jedoch auch feststellen daß ich NTP für meine Anforderungen gar nicht brauche.
MFG
Moin,
Deswegen ja ein NPH Script. Ein solches übern Proxy zu requesten ist völliger Blödsinn.
Welchen Teil meiner Antwort hast du nicht verstanden? Etwa diesen?
ein Proxy […] und warum ich vielleicht hinter einem sitze, den ich nicht unbedingt „einfach mal ausschalten kann“
Viele Grüße
Robert
Natürlich habe ich anhand Deiner header auf den ersten Blick gesehen daß Dein request über einen Proxyserver ging. Was nicht nur Dein header Via beweist sondern die Tatsache daß weitere Header in Deiner Response auftauchten die mein NPH Script gar nicht gesendet hat. MFG
Moin pl,
wie erklärst du dir eigentlich das? Welchen Proxy kann ich denn mit curl manipulieren?
Viele Grüße
Robert
Moin,
Ja. Der Proxy war das. Der hat, hier widersinnig (weil mit größerem Ergebnis), den Content "gepackt". Schau mal, falls Du den verwaltest, in dessen Manual nach ob man das Packen unterhalb von 1k verbieten kann: Bringt dann faktisch nichts.
Viele Grüße
Robert
Moin,
… und der Payload ist interessanter Weise kürzer als die angegebenen 30 Byte:
Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 30Ja. Der Proxy war das. Der hat, hier widersinnig (weil mit größerem Ergebnis), den Content "gepackt".
Hm, anderes Netzwerk ohne Proxy (wäre sonst der Internet-Provider, da kann ich dann nichts machen):
HTTP/1.1 200 OK
Date: Thu, 04 Apr 2019 16:38:36 GMT
Server: Apache
Content-Language: de
x-param: title=FWNG%2C%20modern%20MVC%20Web%20Application%20Framework%20in%20Perl%20und%20in%20C;descr=Modern%20Web%20Framework%20Next%20Generation%20in%20Perl%20und%20in%20C%20programmiert
x-class: HTMLfile
Expires: Sat, 13 Jul 2019 00:00:00 GMT
Last-Modified: Thu, 04 Apr 2019 00:00:00 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 30
Connection: close
Content-Type: text/html; charset=UTF-8
Laut Netzwerk-Tools sind das 516 Byte HTTP-Header und dann noch die 30 Byte Payload 1554395916. Kann es sein, dass der Apache vielleicht packt? Dann testen wir doch einmal:
$ curl -i 'http://rolfrost.de/?time=1'
HTTP/1.1 200 OK
Date: Thu, 04 Apr 2019 16:42:02 GMT
Server: Apache
Content-Language: de
x-param: title=FWNG%2C%20modern%20MVC%20Web%20Application%20Framework%20in%20Perl%20und%20in%20C;descr=Modern%20Web%20Framework%20Next%20Generation%20in%20Perl%20und%20in%20C%20programmiert
x-class: HTMLfile
Expires: Sat, 13 Jul 2019 00:00:00 GMT
Content-Length: 10
Last-Modified: Thu, 04 Apr 2019 00:00:00 GMT
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=UTF-8
1554396122
vs.
$ curl -i --compressed 'http://rolfrost.de/?time=1'
HTTP/1.1 200 OK
Date: Thu, 04 Apr 2019 16:42:31 GMT
Server: Apache
Content-Language: de
x-param: title=FWNG%2C%20modern%20MVC%20Web%20Application%20Framework%20in%20Perl%20und%20in%20C;descr=Modern%20Web%20Framework%20Next%20Generation%20in%20Perl%20und%20in%20C%20programmiert
x-class: HTMLfile
Expires: Sat, 13 Jul 2019 00:00:00 GMT
Last-Modified: Thu, 04 Apr 2019 00:00:00 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 30
Connection: close
Content-Type: text/html; charset=UTF-8
1554396151
Na, wem fällt hier was auf? Von wegen „der Proxy ist es, schalte den ab!“
Der URI auf das NPH-Skript antwortet bei leider mit einem HTTP 404.
Viele Grüße
Robert
Das NPH Script hab ich wieder entfernt, das war nur ein Test. Es ist schon so, daß man mit NPH Scripts bestimmte Dinge performant erledigen kann, insbesondere durch Reduzierung der Header auf das Nötigste. Wenn Dein Server mitspielt kannst Du sogar sowas machen:
#!/usr/bin/perl
binmode STDOUT;
print pack "N", time;
dann hat die ganze Response nur noch 4 Bytes und mit
read($socket, my $bin, 4);
print unpack "N", $bin;
kriegst Du den Zeitstempel genauso wie bei Daytime aus dem Socket gelesen. Letztendlich hab ich mich jedoch für eine HTTP Lösung über mein Framework entschieden, dafür hab ich das ja schließlich auch entwickelt: Erweiterbar um beliebige Webservices ohne daß man dafür ein extra Scripts installieren muss.
So kann ich z.B. die Uhrzeit als Webservice an beliebige URLs binden, da wird einfach nur ein Interface hinzukonfiguriert oder die Klasse erweitert.
MFG
Die Kompression wird übrigens vom Client angefordert. Dafür ist der Request header Accept-Encoding zuständig. Wenn da z.B. gesetzt ist Accept-Encoding: gzip, deflate wird der Server den Message Body nach einem dieser Komprimierungverfahren komprimieren, sofern er das unterstützt.
Daß das nicht immer sinnvoll ist, sehen wird u.a. dran daß z.B. aus einer Zahl mit 10 Ziffern auch mal eine Binary mit der 3fachen Länge werden kann.
Ansonsten wird ein normal konfigurierter Webserver die Daten auch nicht packen wenn das vom Client nicht explizit gewünscht ist. MFG
Hallo pl,
Die Kompression wird übrigens vom Client angefordert. Dafür ist der Request header Accept-Encoding zuständig.
Nein. Der Client teilt mit, dass er die aufgeführten Encodings akzeptiert, hence the name. Was der Server ausliefert ist Sache des Servers. Er muss das nicht beachten.
LG,
CK
Tach!
Die Kompression wird übrigens vom Client angefordert. Dafür ist der Request header Accept-Encoding zuständig.
Nein. Der Client teilt mit, dass er die aufgeführten Encodings akzeptiert, hence the name. Was der Server ausliefert ist Sache des Servers. Er muss das nicht beachten.
Der Client kann auch gar nicht wissen, ob es wert ist, die Daten zu komprimieren. Abgesehen davon muss der Server ja auch nicht die akzeptierten Kompressionstechniken können. Es bleibt also auch so die Entscheidung des Server, ob komprimiert wird.
dedlfix.
hi CK
Nein. Der Client teilt mit, dass er die aufgeführten Encodings akzeptiert, hence the name.
Welche aufgeführten Encodings denn?
Bitte erklären!
hi CK
Bitte erklären!
Verarschen kann ich mich selber.
Bei Deiner Aussage
Nein. Der Client teilt mit, dass er die aufgeführten Encodings akzeptiert,
war das auch mein erster Gedanke. Ich denke jedoch, daß wir es den Mitlesern schuldig sind, auf diese Frage einzugehen: Welche aufgeführten Encodings? Wo bitte hält der Client eine Liste mit Encodings wo er vor dem Request reinschaut!?
Und hier ist die Antwort: Es gibt für den Client keine aufgeführten Encodings. Denn wir befinden uns VOR dem Request.
MFG
Hallo pl,
ich verliere wirklich die Geduld mit dir.
Die Kompression wird übrigens vom Client angefordert. Dafür ist der Request header Accept-Encoding zuständig. Wenn da z.B. gesetzt ist
Accept-Encoding: gzip, deflate
Accept-Encoding ist ein Header, der vom Client geschickt wird. Er ist Teil des Requests und gibt an, welche Encodings der Client akzeptiert. Das kann gzip oder deflate sein, aber auch etwa brotli.
Encoding bezeichnet nicht immer ein Character Encoding. Encoding ist ein generischer Begriff, der Zeichenkodierung heissen kann - aber auch einfach nur Kodierung. Und das ist hier der Fall.
LG,
CK
Moin,
Es gibt für den Client keine aufgeführten Encodings. Denn wir befinden uns VOR dem Request.
Irre! Beim Request selbst gibt es plötzlich diese Liste.
Viele Grüße
Robert
Irre! Beim Request selbst gibt es plötzlich diese Liste.
Genau! Die Frage war aber: Wo das herkommt bzw. wer diesen Header setzt. Ein Client setzt einen Header Accept-Encoding nämlich nicht von selbst! MFG
Hallo pl,
Genau! Die Frage war aber: Wo das herkommt bzw. wer diesen Header setzt. Ein Client setzt einen Header
Accept-Encodingnämlich nicht von selbst! MFG
Ne, die muss der Programmierer definieren. Aber abgesehen davon schickt er sie bei jedem Request, doch.
LG,
CK
Genau! Die Frage war aber: Wo das herkommt bzw. wer diesen Header setzt. Ein Client setzt einen Header
Accept-Encodingnämlich nicht von selbst! MFGNe, die muss der Programmierer definieren. Aber abgesehen davon schickt er sie bei jedem Request, doch.
Der Anwender entscheidet ob die Daten komprimiert werden sollen. Siehe curl --compressed was curl dazu veranlasst diesen Header zu setzen. Steht sogar hier im Thread wie das geht. MFG
Moin,
Der Anwender entscheidet ob die Daten komprimiert werden sollen. Siehe
curl --compressedwas curl dazu veranlasst diesen Header zu setzen. Steht sogar hier im Thread wie das geht.
Im Thread steht auch, dass der Firefox den Header einfach so mitsendet. Wo kann ich das denn dort einstellen? Das ist übrigens ein gutes Beispiel, warum man sich nie nur die Punkte herauspicken sollte, die einem ins Weltbild passen.
Viele Grüße
Robert
Hallo Robert,
Der Anwender entscheidet ob die Daten komprimiert werden sollen. Siehe
curl --compressedwas curl dazu veranlasst diesen Header zu setzen. Steht sogar hier im Thread wie das geht.Im Thread steht auch, dass der Firefox den Header einfach so mitsendet. Wo kann ich das denn dort einstellen?
Macht aber das Argument nicht weniger dumm. Der Anwender entscheidet das im Regelfall nicht, sondern der Hersteller. Der Anwender weiß idR nichtmal, dass es content transfer encoding gibt.
Zugestimmt hätte ich bei „der Anwender kann das bestimmen,“ wäre aber halt auch am Thema vorbei gewesen. Denn es ging ja darum, dass der Client nicht das Transfer-Encoding anfordert, sondern dem Server mitteilt, dass er folgende Transfer-Encodings akzeptiert. Es ist für diese Aussage es halt irrelevant, ob der User das im Client einstellen kann oder nicht.
LG,
CK
Moin,
Genau! Die Frage war aber: Wo das herkommt bzw. wer diesen Header setzt. Ein Client setzt einen Header
Accept-Encodingnämlich nicht von selbst! MFG
Äh, doch. Bei curl kann ich das als Nutzer beeinflussen, beim Browser als Client ist das eingebaut.
Viele Grüße
Robert
Moin pl,
Welche aufgeführten Encodings denn?
Accept-Encoding: gzip, deflate
Das ist direkt aus deinem Posting übernommen.
Viele Grüße
Robert
Deinem Posting hier entnehme ich daß Du schon weißt wie man mit $ curl -i --compressed und ohne diesen Parameter umzugehen hat. Ergebnis ebenda.
Tipp: Nimm mal einen Networkanalyzer wie Wireshark und guck Dir an welche Requestheader raus gehen, mit oder ohne --compressed. MFG
Was bitte ist an der Idee Datum + Uhrzeit als Webservice schlecht!?
Bitte eine genaue Begründung!
Tach!
Was bitte ist an der Idee
Datum + Uhrzeit als Webserviceschlecht!?
Der zweifelhafte Nutzen gegenüber deutlich genaueren Verfahren. Die meisten Systeme haben bereits eine relativ genaue Uhrzeit an Bord, meist sogar dauerhaft angezeigt, und haben eingebaute oder leicht nachrüstbare Synchronisationssoftware. Warum nicht einfach die Systemzeit nehmen? Und wenn es nicht auf die exakte Zeit ankommt, ist auch die Synchronisation verzichtbar.
dedlfix.
Tach!
Was bitte ist an der Idee
Datum + Uhrzeit als Webserviceschlecht!?Der zweifelhafte Nutzen gegenüber deutlich genaueren Verfahren. Die meisten Systeme haben bereits eine relativ genaue Uhrzeit an Bord, meist sogar dauerhaft angezeigt, und haben eingebaute oder leicht nachrüstbare Synchronisationssoftware. Warum nicht einfach die Systemzeit nehmen? Und wenn es nicht auf die exakte Zeit ankommt, ist auch die Synchronisation verzichtbar.
Nutzen und Idee sind 2 verschiedene Dinge! Hinter der Idee der Webservices steckt der Gedanke der Vielfältigkeit.
MFG
Hallo,
Der zweifelhafte Nutzen
Angenommen du hättest ne Smartwatch, die könnte über die Internetverbindung des dazupassenden Smartphone jetzt direkt den Webservice aufrufen und dadurch die Zeit samt Datum anzeigen!
Gruß
Kalk
Moin,
Neben der Idee Zeit als Webservice ist es im Übrigen überhaupt kein Problem, das ganze Protokoll NTP über HTTP abzuwickeln. Und zwar ganz genauso wie das der RFC beschreibt. Da spielen dann auch die Laufzeiten keine Rolle mehr, NTP beschreibt ja wie man die rausrechnet. Es ist dann auch egal ob ein Proxy im Spiel ist. Somit lässt sich also auch über HTTP/TCP dieselbe Genauigkeit erreichen wie über UDP.
Schönes Wochenende!
Tach!
Neben der Idee
Zeit als Webserviceist es im Übrigen überhaupt kein Problem, das ganze Protokoll NTP über HTTP abzuwickeln.
Das ist nichts neues, dass man Protokolle über andere Protokolle tunneln kann. Das macht die Idee, die Uhrzeit als Webservice anzubieten nicht weniger uninteressant.
dedlfix.
Hab ich was von tunneln geschrieben!?
Tach!
Hab ich was von tunneln geschrieben!?
So nennt man das jedenfalls, wenn man ein Protokoll "über ein anderes abwickelt". Falls du das nicht so gemeint hast: "Besser formulieren hilft Missverständnisse vermeiden."
dedlfix.
Moin,
Neben der Idee
Zeit als Webserviceist es im Übrigen überhaupt kein Problem, das ganze Protokoll NTP über HTTP abzuwickeln. Und zwar ganz genauso wie das der RFC beschreibt. Da spielen dann auch die Laufzeiten keine Rolle mehr, NTP beschreibt ja wie man die rausrechnet. Es ist dann auch egal ob ein Proxy im Spiel ist. Somit lässt sich also auch über HTTP/TCP dieselbe Genauigkeit erreichen wie über UDP.
PS: Demo
Moin,
Was bitte ist an der Idee
Datum + Uhrzeit als Webserviceschlecht!?Bitte eine genaue Begründung!
Der Overhead im Worst-Case spricht IMHO dagegen. Wie ich schon schrieb:
Es gibt Proxies, sie sind erlaubt und sie werden verwendet.
Ein Webservice, der von seinem Anwender einen (möglicherweise nicht gestatteten) Eingriff in Proxy-Einstellungen benötigt um performant zu sein, ist einfach käse, vor allem, wenn es sinnvolle Alternativen gibt, die diesen Overhead im schlimmsten Fall nicht haben.
Viele Grüße
Robert
So isses. Es gibt immer Alternativen, auch für Webservices. Und genau das ist ja die Idee: Die Vielgestaltigkeit. Das bedeutet auch für Anwender einen Mehrgewinn: Er kann wählen! Wenn eine Policy für seinen AP alle Ports blockiert die nicht Port 80//443 sind hat er immer noch die Möglichkeit seine Daten über einen Webservice zu beziehen. MFG
pool.ntp.org ist zeitlich genauso gut wie die Server der PTB, dafür aber ausfallsicher, da einige tausend Server vorhanden (für Deutschland: de.pool.ntp.org oder europe.pool.ntp.org).
Außerdem wird die Behörde nicht unnötig belastet. Schon wenn es einfach nur darum geht, die Uhrzeit auf die Sekunde zu haben, scheint mir eine Synchronisation direkt mit der PTB ein wenig frech, weil vollkommen unnötige Verschwendung von Steuergeldern.
Rechenzentrumsbetreiber stellen übrigens teils ebenfalls eigene NTP-Server zur Verfügung.
Danke für die INFO! Überhaupt hat ja die Frage der Belastbarkeit dahin geführt UDP stat TCP einzusetzen. Wie beim DNS. MFG
Der Vollständigkeit halber für Telefonanschlüsse:
Telekom: ntp1.telekom.de
o2: ntp0.voip.telefonica.de, ntp1.voip.telefonica.de
Vodafone / Kabel Deutschland: Hat zwar de.pool.ntp.arcor-ip.net, die Adresse verweist aber lediglich auf de.pool.ntp.org
Unitymedia: ntp.unitymedia.com
1&1: time.versatel.de
Ewetel: ntp.ewetel.de
Fritzbox: Die Fritzbox kann als lokaler Zeitserver arbeiten. Die Einstellung befindet sich unter Heimnetz -> Heimnetzübersicht -> Netzwerkeinstellungen. Am Ende der Seite lässt sich der lokale Zeitserver aktivieren und auch die Server benennen, von denen die Fritzbox ihre Zeit bezieht. Bei manchen Telefonanschlüssen wird letztere Einstellung auch automatisch gesetzt.
Der Vollständigkeit halber: NTP ist ähnlich aufgebaut wie DNS. NTP ist natürlich viel mehr als nur ein Webservice. Das Protokoll und das damit verbundene Datenpaket ermöglicht einen bidirektionalen Datenaustausch, so kann ein NTP Server gleichzeitig ein NTP Client sein und mit anderen Servern kommunizieren. Als sog. Peer vergleicht er seine eigene Zeit mit mehreren anderen NTP-Peers, die sich schließlich auf eine gemeinsame Zeit einigen, nach der sich dann alle richten. Über diese Rollenverteilung kann auf einfache Weise eine hierarchische Zeitverteilung in einem Netzwerk eingerichtet werden. Die einzelnen Hierarchie-Ebenen werden Stratum (Horizont) genannt. Eine kleinerer Stratum-Wert bedeutet dabei eine höhere Ebene in der Hierarchie-Struktur.
Btw., im DNS heißen die ganz oben Rootserver. Aber die einen habens eben so genannt und die anderen so. SO
Viel Spaß damit!
Und was leitest Du aus dem BEISPIEL für Dich ab?
Ich sehe nur, dass der Autor etwas einfaches und eingängiges für seine Erläuterungen brauchte. Und wie das halt oft ist, hat das WSDL-Beispiel keinerlei konkrete technische Relevanz.
Für diejenigen, die das Zeug gar nicht mehr kennen:
Die Web Services Description Language (WSDL) ist eine plattform-, programmiersprachen- und protokollunabhängige Beschreibungssprache für Netzwerkdienste (Webservices) zum Austausch von Nachrichten auf Basis von XML.
Übrigen ist WSDL sowas von "tot":
Am 15. März 2001 veröffentlichte das World Wide Web Consortium die Web Service Description Language (WSDL) Note Version 1.1. Am 26. Juni 2007 wurde die Version 2.0 veröffentlicht, die sich in zwei Teile zur Sprachdefinition („Core Language“) und Zusätze („Adjuncts“) gliedert.
Als man vor mehr als 10 Jahren erkannte, dass Java und XML nicht die alleinigen Glücksbringer sind und die Buzzwortbläser aus den Vertriebsabteilungen neue Slogans für neues teures, überkandideltes und minderperformantes Zeug brauchten zog der Zirkus weiter…
Hallo ursus,
Übrigen ist WSDL sowas von "tot":
Schön wärs. Leider ist das in der Industrie immer noch weit verbreitet und will einfach nicht aussterben.
LG,
CK
und will einfach nicht aussterben.
Ja. Ich weiß. Mein super-vorbereitetes "Apache-Webserver mit eigenen, vom PKI-beglaubigten SSL/TLS-Zertifikaten in einer Windows Domain"-Seminar von gestern und vorgestern artete zu einem "Tomcat unter Windows mit öffentlichen Zertifikaten"-Labor aus...
Das konkrete Problem konnte ich lösen. Ich staune aber immer wieder, welchen gigantischen Aufwand man betreiben kann um mit fetten Servern und riesigem Administrationsaufwand Kleinkram zu erledigen, den ich wesentlich performanter mit einer Hand voller Skripte auf einem Raspi ...
Moin Christian,
Übrigen ist WSDL sowas von "tot":
Schön wärs. Leider ist das in der Industrie immer noch weit verbreitet und will einfach nicht aussterben.
trotz dem alleine glücklich und selig machenden JSON hält sich das immer noch? Interessant. Aber es gibt ja auch noch OData 😉
Viele Grüße
Robert
Tach!
Schön wärs. Leider ist das in der Industrie immer noch weit verbreitet und will einfach nicht aussterben.
trotz dem alleine glücklich und selig machenden JSON hält sich das immer noch?
Die Geschwindigkeit, mit der viele Unternehmen ihre meist geschäftskritische Software aktualisieren, ist häufig ähnlich der von Kontinentalplattenverschiebungen. Warum auch nicht, wenn es doch läuft und teuer war und beim nächsten Update wieder werden wird.
dedlfix.
Hi,
Die Geschwindigkeit, mit der viele Unternehmen ihre meist geschäftskritische Software aktualisieren, ist häufig ähnlich der von Kontinentalplattenverschiebungen. Warum auch nicht, wenn es doch läuft und teuer war und beim nächsten Update wieder werden wird.
Beispiel aus dem realen Leben:
eine neue Bank ist auf dem Markt aufgetaucht, IIRC im Juni.
Ein paar Wochen später, im Juli, schlug eine Übertragung von Kundendaten zu einem Vertragspartner fehl, weil der Kunde die neue Bank nutzt.
Anfrage beim Vertragspartner ergab: wir nehmen die Bank beim nächsten Software-Release mit auf, also Ende April.
cu,
Andreas a/k/a MudGuard
Die Geschwindigkeit, mit der viele Unternehmen ihre meist geschäftskritische Software aktualisieren, ist häufig ähnlich der von Kontinentalplattenverschiebungen.
Das Gros der Unternehmen hält tatsächlich länger als drei, vier Jahre durch und verdient, oh Wunder, sogar Geld. Das mag manchen gestandenen IT-Professional verwundern, der schon 20 Startups in Berlin-Mitte in den Sand gesetzt hat, obwohl er doch immer mit der Nase vorn war, heute schon benutzte, was morgen die Beta verlassen würde, vielleicht.
Aber der Trick ist, dass diese Unternehmen ihre Gerätschaften benutzen um Rechnungen zu schreiben, und nicht um alle Nase lang wieder die jetzt aber wirklich allerneuesten, ganz bestimmt total kompatiblen, garantiert betriebssicheren Softwarefeatures zu installieren.
Warum auch nicht, wenn es doch läuft
Eben. Es läuft. Was ist so schlimm an Software, die auch nach zwanzig Jahren noch das tut, was sie soll? Man verliert andauernd beim Bullshit-Bingo der Startup-Szene?