06.04. ICMP llaikspiedoga pieprasījums un atbilde

Pēdējais mainījis Administrator 2011-06-06 17:16

06.04. ICMP laikspiedoga pieprasījums un atbilde

Linux 2.6 vajadzībām izveidots 'icmptime' rīks

ICMP laikspiedoga pieprasījums ļauj vienai sistēmai pavaicāt citai sistēmai pareizu laiku. Ieteicamā atgriežamā vērtība ir milisekunžu skaits kopš pusnakts, Koordinētā universālā laika (UTC). (Vecākas rokasgrāmatas UTC sauc par Griničas vidējo laiku). Patīkamā iezīme šim ICMP ziņojumam ir tā, ka tā nodrošina milisekunžu izšķirtspēju, kamēr dažas citas metodes laika iegūšanai no citas mītnes (piemēram rdate komanda, ko piedāvā dažas UNIX sistēmas) izšķirtspēju dod sekundēs. ICMP laikspiedoga metodes trūkums - tā kā atgrieztais laiks ir kopš pusnakts, izsaucējam pašam ar kādu metodi ir jānosaka pašreizējais laiks. 6.6.attēls parāda ICMP laikspiedoga pieprasījuma un atbildes ziņojuma formātu:

#pic("f_6_6.gif", "500")
6.6.attēls: ICMP laikspiedoga pieprasījuma un atbildes ziņojumi

Pieprasītājs aizpilda savu sākotnējo laikspiedogu un nosūta ziņojumu. Atbildošā sistēma, kad tā saņem pieprasījumu, aizpilda saņemšanas laikspiedogu, un nosūtīšanas laikspiedogu, kad tā nosūta atbildi. Patiesībā vairumā sistēmu abiem šiem laukiem ir viena un tā pati vērtība. (Visu trīs lauku esamības iemesls ir ļaut sūtītājam aprēķināt laiku pieprasījuma nosūtīšanai un atsevišķi izrēķināt laiku atbildes nosūtīšanai.)

Varam uzrakstīt vienkāršu programmu, ko sauc icmptime, kas sūta ICMP laikspiedoga pieprasījumu uz kādu mītnes datoru un drukā atgriezto atbildi. Vispirms mēģinām to mūsu mazajā internetā:

sun % icmptime bsdi
orig = 83573336, recv = 83573330, xmit = 83573330, rtt = 2 ms
difference = -6 ms
sun % icmptime bsdi
orig = 83577987, recv = 83577980, xmit = 83577980, rtt = 2 ms
difference = -7 ms

Programma drukā trīs laikspiedogus, kas ietverti ICMP ziņojumā - sākuma (originate, orig), saņemšanas (receive, recv) un pārsūtīšanas (transmit, xmit). Kā redzēsim šajā un turpmākajos piemēros, visas mītnes uzstāda saņemšanas un pārsūtīšanas laikposmus uz to pašu vērtību.

Aprēķinām arī #term("aprites", "round_trip") ceļa laiku (rtt), kas ir starpība starp atbildes saņemšanas laiku un pieprasījuma izsūtīšanas laiku. Šī starpība ir saņemšanas brīža laikspiedogs (received timestamp) mīnus sākuma laikspiedogs (originate laikspiedogs. 6.7.attēls parāda attiecības starp šīm vērtībām.

#pic("f_6_7.gif", "500")
6.7.attēls: Attiecības starp vērtībām, ko drukā 'icmptime' programma

Ja mēs ticam RTT, un pieņemam, ka puse no RTT ir pieprasījuma ceļš, bet otra puse - atbildes ceļš, tad sūtītāja pulksteni vajag izmainīt par starpību mīnus puse no RTT, lai tam būtu tāds pats laiks kā mītnei, kurai sūta pieprasījumu. Iepriekšējā piemērā pulkstenis uz bsdi bija 7 un 8 ms vēlāks nekā pulkstenis uz sun.

Tā kā laikspiedogu vērtības ir milisekunžu skaits pāri pusnaktij, UTC, tās vienmēr ir mazākas par 86,400,000 (24 x 60 x 60 x 1000). Šos piemērus darbināja īsi pirms 16:00 laika joslā, kas ir 7 stundas vēlāka nekā UTC, tad vērtības tuvu pie 82,800,000 (23.00 stundas) izskatās ticamas

Ja darbinām šo programmu vairākas reizes uz to pašu mītni bsdi, redzam, ka pēdējais cipars saņemšanas un pārsūtīšanas laikspiedogā vienmēr ir 0. Tas ir tādēļ, ka programmatūras #term("laidiens", "release") (Versija 0.9.4) nodrošina pulksteni ar 10 ms precizitāti (Šo situāciju sīkāk aprakstīsim Pielikumā B.).

Ja darbinām šo programmu divreiz uz mītni svr4 redzam, ka pat trīs jaunāko kārtu cipari svr4 laikspiedogos ir vienmēr 0:

sun % icmptime svr4
orig = 83588210, recv = 83588000, xmit = 83588000, rtt = 4 ms
difference = -210 ms
sun % icmptime svr4
orig = 83591547, recv = 83591000, xmit = 83591000, rtt = 4 ms
difference = -547 ms

Kaut kādu iemeslu dēļ svr4 nenodrošina nekādu milisekunžu izšķirtspēju, izmantojot ICMP laikspiedogu. Šī neprecizitāte padara aprēķinātās starpības par nederīgām, regulējot pulksteņus līdz milisekunžu vērtībām.

Ja izmēģinām divas citas mītnes 140.252.1 apakštīklā, rezultāti parāda, ka viens pulkstenis atšķiras no sun pulksteņa par 3.7 sekundēm, bet otrs - gandrīz par 75 sekundēm:

sun % icmptime gemini
orig = 83601883, recv = 83598140, xmit = 83598140, rtt = 247 ms
difference = -3743 ms
sun % icmptime aix
orig = 83606768, recv = 83532183, xmit = 83532183, rtt = 253 ms
difference = -74585 ms

Cits interesants piemērs ir, sūtot uz maršrutētāja vārteju (Cisco maršrutētāju). Tas parāda, ka tad, ja sistēma atgriež nestandarta laikspiedoga vērtību (kaut ko citu nekā milisekundes kopš UTC pusnakts), tai vajadzētu ieslēgt vecāko bitu 32-bitu laikspiedogā. Mūsu programma to pamana un drukā saņemšanas un nosūtīšanas laikspiedogus leņķiskajās iekavās (pēc vecākā bita izslēgšanas). Gluži tāpat - mēs nevaram aprēķināt atšķirību starp sākuma un saņemšanas laikspiedogiem, jo tie nav izteikti vienās mērvienībās.

sun % icmptime gateway
orig = 83620811, recv = <4871036>, xmit = <4871036>, rtt = 220 ms
sun % icmptime gateway
orig = 83641007, recv = <4891232>, xmit = <4891232>, rtt = 213 ms

Ja darbinām savu programmu uz šo mītni vairākas reizes, kļūst redzams, ka atgrieztās vērtības ir ar milisekunžu izšķirtspēju un skaita milisekunžu skaitu kopš kāda atskaites punkta, bet šis atskaites punkts nav UTC pusnakts. (Tas, piemēram, varētu būt skaitītājs, kurš tiek palielināts ik milisekundi kopš maršrutētāja sāknēšanas.).

Kā beidzamo piemēru mēs salīdzināsim sun'a pulksteni ar sistēmu, kuras pulkstenis ir zināms kā precīzs - NTP stratum 1 serveris. (Par NTP #term("Tīkla Laika Protokolu", "Network_Time_Protocol") mēs runāsim tālāk).

sun % icmptime clock.llnl.gov
orig = 83662791, recv = 83662919, xmit = 83662919, rtt = 359 ms
difference = 128 ms
sun % icmptime clock.llnl.gov
orig = 83670425, recv = 83670559, xmit = 83670559, rtt = 345 ms
difference = 134 ms

Aprēķinot laika starpību mīnus pusi no RTT, šī izvade norāda, ka pulkstenis uz sun'a visticamāk steidzas par laiku starp 38.5 un 51.5 ms.

Alternatīvas

Ir citi veidi, kā iegūt laiku un datumu.

  1. 1.12.nodaļā aprakstījām daytime servisu un time servisu. Pirmais atgriež pašreizējo laiku un datumu cilvēkam lasāmā formā, ASCII simbolu virknīti. Varam pārbaudīt šo servisu, izmantojot telnet komandu:
    sun % telnet bsdi daytime
    Trying 140.252.13.35 ...
    Connected to bsdi.
    Escape character is "^]"                (3 rindas - Telnet klienta paziņojums)
    Wed Feb 3 16:38:33 1993                 ('daytime' servisa izvade)
    Connection closed by foreign host. 	(Telnet klienta paziņojums)
    'time' serveris turpretī atgriež 32-bitu bināru vērtību, kur glabājas sekunžu skaits kopš 1900.g. 1.janvāra, UTC. Lai gan tas ļauj noskaidrot datumu, laika vērtība izteikta sekundēs. (Komanda rdate, ko jau minējām, izmanto šo TCP 'time' servisu)
  2. Nopietni laika mērītāji izmanto #term("Tīkla Laika Protokolu", "Network_Time_Protocol") (NTP), ko apraksta RFC 1305 [Mills 1992]. Šis protokols izmanto izsmalcinātu tehnoloģiju, lai uzturētu pulksteņus sistēmu grupai LANā vai WANā līdz pat milisekundes precizitātei. Ikviens, kuram interesē precīza laika mērīšana datoros, var izlasīt šo RFC.
  3. #term("Atvērtās Programmatūras Fonda", "Open_Software_Foundation") (OSF) #term("Dalītās Skaitļošanas Vide", "Distributed_Computing_Environment") (DCE) definē #term("Dalīto Laika Servisu", "Distributed_Time_Service") (DTS), kas arī nodrošina pulksteņu sinhronizēšanu starp datoriem. [Rosenberg, Kenney, and Fisher 1992] detalizēti apraksta šo servisu.
  4. Bērklija UNIX'a sistēmas nodrošina #term("dēmonu", "daemon") timed(8), lai sinhrinizētu pulksteņus sistēmām #term("lokālajā tīklā", "local_area_network"). Atšķirībā no NTP un DTS, timed nestrādā #term("lielizmēra tīklos", "wide_area_network").
Tagi:
Izveidojis Kalvis Apsītis 2008-05-04 22:13
    
This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 6.4 - Documentation