06.04. ICMP laikspiedoga pieprasījums un atbilde

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

#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 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 msProgramma 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ī aprites ceļa laiku (

#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 laidiens (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: 

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: 

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. 

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 Tīkla Laika Protokolu mēs runāsim tālāk). 

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: 

 '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)

1. Nopietni laika mērītāji izmanto Tīkla Laika Protokolu (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. 
2. Atvērtās Programmatūras Fonda (OSF) Dalītās Skaitļošanas Vide (DCE) definē Dalīto Laika Servisu (DTS), kas arī nodrošina pulksteņu sinhronizēšanu starp datoriem. [Rosenberg, Kenney, and Fisher 1992] detalizēti apraksta šo servisu.
3. Bērklija UNIX'a sistēmas nodrošina dēmonu timed(8), lai sinhrinizētu pulksteņus sistēmām lokālajā tīklā. Atšķirībā no NTP un DTS, timed nestrādā lielizmēra tīklos.