Wat is NFS? Netwerk bestandssysteem. Bestandssysteem netwerktoegangsprotocol. NFS-prestaties verbeteren. Standaardrechten instellen

Procedureoproep op afstand op afstand

Afbeelding 29.1 RPC-procedureaanroepberichten in UDP-datagramformaat.

De standaard IP- en UDP-headers zijn eerder weergegeven (Figuur 3.1 en Figuur 11.2). Alles na de UDP-header wordt bepaald door het RPC-pakket.

De transactie-ID (XID - transactie-ID) wordt ingesteld door de client en geretourneerd door de server. Wanneer de client een reactie ontvangt, vergelijkt deze de door de server geretourneerde XID met de XID van het verzonden verzoek. Als ze niet overeenkomen, negeert de klant het bericht en wacht tot het volgende bericht arriveert. Elke keer dat een klant een nieuwe RPC uitgeeft, verandert deze de XID. Als de client de RPC echter opnieuw verzendt (als er geen antwoord is ontvangen), verandert de XID niet.

De variabele call is 0 voor de call en 1 voor de response. De huidige RPC-versie is 2. De volgende drie variabelen, programmanummer, versienummer en procedurenummer, identificeren de specifieke procedure die op de server moet worden aangeroepen.

Referenties identificeren de klant. In sommige voorbeelden wordt dit veld leeg gelaten, terwijl u in andere de digitale gebruikers-ID en de groeps-ID kunt vinden waartoe hij behoort. De server kan de inloggegevens bekijken en beslissen of het verzoek moet worden verwerkt of niet. Verifier wordt gebruikt voor Secure RPC (Secure RPC), die DES-codering gebruikt. Hoewel de autorisatie- en validatievelden velden met variabele lengte zijn, wordt hun lengte als onderdeel van het veld verzonden.

De parameters van de procedure volgen. Hun formaat hangt af van hoe de toepassing de procedure op afstand definieert. Hoe weet de ontvanger (serverstub) de grootte van de parameters? Omdat UDP wordt gebruikt, kan de grootte van de parameters worden berekend als de grootte van het UDP-datagram minus de lengte van alle velden tot aan het controleveld. Wanneer TCP wordt gebruikt in plaats van UDP, is er geen concept van vaste lengte, aangezien TCP een stroom van bytes is zonder recordscheidingstekens. In dit geval verschijnt een veld met een lengte van 4 bytes tussen de TCP-header en de XID, waaruit de ontvanger de lengte van de RPC-oproep in bytes weet. Hierdoor kan het RPC-oproepbericht indien nodig op meerdere TCP-segmenten worden verzonden. (DNS gebruikt een vergelijkbare techniek; Oefening 4 in hoofdstuk 14.)

Figuur 29.2 toont het formaat van het RPC-antwoord. Het wordt verzonden van de server-stub naar de client-stub wanneer de externe procedure wordt afgesloten.

Afbeelding 29.2 Indeling van het RPC-antwoordbericht als UDP-datagram.

De XID van de oproep wordt eenvoudig gekopieerd naar de XID van de respons. Het antwoordveld is 1, wat onderscheid maakt tussen een uitdaging en een reactie. Het statusveld is nul als het oproepbericht is geaccepteerd. (Het bericht kan worden weggegooid als het RPC-versienummer niet 2 is, of als de server de client niet kan authenticeren.) Het verificatieveld wordt gebruikt in het geval van beveiligde RPC om de server aan te geven.

Het acceptatiestatusveld is nul als alles in orde is. Een waarde die niet nul is, kan bijvoorbeeld een ongeldig versienummer of een ongeldig procedurenummer aangeven. Als TCP wordt gebruikt in plaats van UDP, wordt, net als bij het RPC-uitdagingsbericht, een veld met een lengte van 4 bytes verzonden tussen de TCP-header en de XID.

External Data Representation (XDR) is een standaard die wordt gebruikt om waarden te coderen in RPC-oproep- en antwoordberichten - RPC-headervelden (XID, programmanummer, ontvangststatus, enzovoort), procedureparameters en procedureresultaten. De standaard manier om gegevens te coderen stelt een klant in staat om een ​​procedure aan te roepen op een systeem met een andere architectuur. XDR is gedefinieerd in RFC 1014 [Sun Microsystems 1987].

XDR definieert een aantal gegevenstypen en de exacte manier waarop ze worden overgedragen in een RPC-bericht (bitvolgorde, bytevolgorde, enzovoort). De afzender moet het RPC-bericht in XDR-formaat construeren, waarna de ontvanger het XDR-formaat naar zijn oorspronkelijke weergave converteert. (In het formaat dat voor zijn systeem wordt geaccepteerd.) We zien bijvoorbeeld in de figuren 29.1 en 29.2 dat alle gehele waarden die we hebben weergegeven (XID, oproep, programmanummer, enzovoort) 4-byte gehele getallen zijn . Alle gehele getallen in XDR zijn inderdaad 4 bytes. XDR ondersteunt andere gegevenstypen, waaronder integers zonder teken, booleans, floating point getallen, arrays met vaste lengte, arrays met variabele lengte en structuren.

Server-RPC-programma's die procedures op afstand bevatten, gebruiken dynamisch toegewezen poorten in plaats van vooraf bekende poorten. Dit vereist een vorm van "registratie" om constant informatie te hebben over welke dynamisch toegewezen poort een bepaald RPC-programma gebruikt. Sun RPC noemt deze registrar een port mapper. (Een port mapper is een server die RPC-programmanummers converteert naar DARPA-protocolpoortnummers. Deze server moet actief zijn om een ​​RPC-oproep te doen.)

In feite moet de poortmapper zelf een bekende poort hebben: UDP-poort 111 en TCP-poort 111. Een poortmapper is slechts een RPC-serverprogramma. Het heeft een programmanummer (100000), versienummer (2), TCP-poort 111 en UDP-poort 111. Servers registreren elkaar bij de poortmapper met behulp van RPC-aanroepen, en clients vragen de poorttoewijzer aan met behulp van RPC-aanroepen. De poorttoewijzer biedt vier serverprocedures:

1. PMAPPROC_SET. Aangeroepen door de RPC-server bij het opstarten om het programmanummer, het versienummer en het protocol in de poorttoewijzing te registreren.
2. PMAPPROC_UNSET. Aangeroepen door de server om een ​​eerder geregistreerde transformatie te verwijderen.
3. PMAPPROC_GETPORT. Geroepen door de RPC-client bij het opstarten om het poortnummer voor het opgegeven programmanummer, versienummer en protocol te krijgen.
4. PMAPPROC_DUMP. Retourneert alle items (programmanummer, versienummer, protocol en poortnummer) naar de database van de poortconverter.

Wanneer het RPC-serverprogramma start en later wanneer het wordt aangeroepen door het RPC-clientprogramma, worden de volgende stappen uitgevoerd.

1. De poortconverter moet eerst worden gestart, meestal bij het opstarten van het systeem. Dit creëert een TCP-eindpunt en opent passief TCP-poort 111. Het creëert ook een UDP-eindpunt dat wacht tot een UDP-datagram arriveert op UDP-poort 111.
2. Bij het opstarten maakt het RPC-serverprogramma een TCP-eindpunt en een UDP-eindpunt aan voor elke ondersteunde versie van het programma. (Een RPC-programma kan meerdere versies ondersteunen. De client specificeert de vereiste versie bij het aanroepen van een serverprocedure.) Aan elk eindpunt wordt een dynamisch toegewezen poortnummer toegewezen. (Het maakt niet uit of de TCP- en UDP-poortnummers hetzelfde of verschillend zijn.) De server registreert elk programma, elke versie, elk protocol en elk poortnummer door op afstand een oproep te doen naar de poorttoewijzingsroutine PMAPPROC_SET.
3. Wanneer het RPC-clientprogramma start, roept het de poorttoewijzingsroutine PMAPPROC_GETPORT aan om het dynamisch toegewezen poortnummer voor het gegeven programma, de versie en het protocol te krijgen.
4. De client stuurt een RPC-uitdagingsbericht naar het poortnummer dat in stap 3 is verkregen. Als UDP wordt gebruikt, stuurt de client eenvoudig een UDP-datagram met het RPC-uitdagingsbericht (Figuur 29.1) naar het UDP-poortnummer van de server. Als reactie stuurt de server een UDP-datagram met een RPC-antwoordbericht (Figuur 29.2). Als TCP in gebruik is, maakt de client een actieve openstelling voor het TCP-poortnummer van de server en verzendt vervolgens een RPC-oproepbericht via de verbinding. De server reageert met een RPC-antwoordbericht via de verbinding.

Het programma rpcinfo (8) drukt alle huidige instellingen van de poortconverter af. (Dit is waar de PMAPPROC_DUMP port mapper routine wordt aangeroepen.) Typische output wordt hieronder getoond:

Zon% / usr / etc / rpcinfo -p
programma versus protopoort
100005 1 tcp 702 mountd NFS mount daemon
100005 1 udp 699 gemonteerd
100005 2 tcp 702 gemonteerd
100005 2 udp 699 gemonteerd

100003 2 udp 2049 nfs NFS zelf

100021 1 tcp 709 nlockmgr NFS lock manager
100021 1 udp 1036 nlockmgr
100021 2 tcp 721 nlockmgr
100021 2 udp 1039 nlockmgr
100021 3 tcp 713 nlockmgr
100021 3 udp 1037 nlockmgr

We kunnen zien dat sommige programma's meerdere versies ondersteunen, en elke combinatie van programmanummer, versienummer en protocol heeft zijn eigen toewijzing van poortnummers die door de poortmapper worden bediend.

Beide versies van de mount-daemon zijn toegankelijk via hetzelfde TCP-poortnummer (702) en hetzelfde UDP-poortnummer (699), maar elke versie van de blokkeringsmanager heeft zijn eigen poortnummer.

NFS biedt klanten transparante toegang tot de bestanden en het bestandssysteem van de server. Dit in tegenstelling tot FTP (hoofdstuk 27), dat bestandsoverdrachten biedt. Met behulp van FTP wordt een volledige kopie van het bestand gemaakt. NFS heeft alleen toegang tot de delen van het bestand waartoe het proces toegang heeft gehad, en het belangrijkste voordeel van NFS is dat het deze toegang transparant maakt. Dit betekent dat elke clienttoepassing die met een lokaal bestand kan werken, net zo goed met een NFS-bestand kan werken, zonder enige aanpassingen aan het programma zelf.

NFS is een client-servertoepassing die is gebouwd met Sun RPC. NFS-clients hebben toegang tot bestanden op de NFS-server door RPC-verzoeken naar de server te sturen. Dit kan worden geïmplementeerd met behulp van normale gebruikersprocessen - namelijk de NFS-client kan een gebruikersproces zijn dat specifieke RPC-aanroepen naar de server doet, wat ook een gebruikersproces kan zijn. NFS wordt echter meestal om twee redenen anders geïmplementeerd. Ten eerste moet toegang tot NFS-bestanden transparant zijn voor de klant. Daarom worden oproepen naar de NFS-client gedaan door het clientbesturingssysteem namens het gebruikersproces van de client. Ten tweede worden NFS-servers in het besturingssysteem geïmplementeerd om de efficiëntie van de server te verbeteren. Als de NFS-server een gebruikersproces zou zijn, moet elk clientverzoek en elke serverreactie (inclusief gegevens die moeten worden gelezen of geschreven) door een scheidingsteken gaan tussen de kernel en het gebruikersproces, wat over het algemeen vrij duur is.

In deze sectie zullen we kijken naar versie 2 van NFS zoals gedocumenteerd in RFC 1094 [Sun Microsystems 1988b]. Voor een betere beschrijving van Sun RPC, XDR en NFS, zie [X / Open 1991]. Voor details over het gebruik en beheer van NFS, zie [Stern 1991]. De specificaties van het NFS-protocol versie 3 werden in 1993 geïmplementeerd, waarover we in een gedeelte van dit hoofdstuk zullen praten.

Afbeelding 29.3 toont typische NFS-client- en NFS-serverinstellingen. In deze afbeelding moet u op het volgende letten.

1. Het maakt de client niet uit of het een lokaal bestand of een NFS-bestand benadert. De kernel detecteert dit wanneer het bestand geopend is. Nadat het bestand is geopend, geeft de kernel alle aanroepen naar lokale bestanden door aan het vak gemarkeerd als "toegang tot lokale bestanden", en alle links naar NFS-bestanden worden doorgegeven aan het vak "NFS-client".
2. De NFS-client stuurt RPC-verzoeken naar de NFS-server via de TCP / IP-module. NFS gebruikt meestal UDP, maar nieuwere implementaties kunnen TCP gebruiken.
3. De NFS-server ontvangt verzoeken van de client als UDP-datagrammen op poort 2049. Hoewel NFS kan werken met een poorttoewijzing, waardoor de server dynamisch toegewezen poorten kan gebruiken, is UDP-poort 2049 in de meeste implementaties hard gecodeerd naar NFS.

Afbeelding 29.3 Typische NFS-client en NFS-serverinstellingen.

De meeste Unix-hosts kunnen functioneren als een NFS-client en een NFS-server, of beide. De meeste pc-implementaties (MS-DOS) hebben alleen NFS-clientimplementaties. De meeste IBM-mainframes bieden alleen NFS-serverfunctionaliteit.

NFS is echt meer dan alleen een NFS-protocol. Figuur 29.4 toont de verschillende RPC-programma's die met NFS worden gebruikt.

Figuur 29.4 Verschillende RPC-programma's die in NFS worden gebruikt.

De mount-daemon wordt aangeroepen op de NFS-host van de client voordat de client toegang heeft tot het bestandssysteem van de server. We zullen dit proces hieronder beschrijven.

Met de vergrendelingsmanager en de statusmonitor kan de client sommige bestanden op de NFS-server vergrendelen. Deze twee programma's zijn onafhankelijk van het NFS-protocol, omdat voor blokkering client-identificatie op zowel de client-host als de server vereist is, en NFS zelf is "onverschillig". (We hebben het hieronder in meer detail over NFS-onverschilligheid.) Hoofdstukken 9, 10 en 11 van [X / Open 1991] documenteren de procedures die de vergrendelingsmanager en de statusmonitor gebruiken om in NFS te vergrendelen.

Een van de fundamenten van NFS wordt geïmplementeerd door bestandsdescriptors. Gebruik opaque om toegang te krijgen tot een bestand of map op de objectserver. De term ondoorzichtig betekent dat de server een bestandsdescriptor maakt, deze teruggeeft aan de client, die de client vervolgens gebruikt bij het openen van het bestand. De client kijkt nooit naar de inhoud van de bestandsdescriptor - de inhoud is alleen van belang voor de server.

Een NFS-client ontvangt een bestandsdescriptor elke keer dat het een bestand opent dat zich daadwerkelijk op de NFS-server bevindt. Wanneer een NFS-client dit bestand leest of schrijft (namens een gebruikersproces), wordt de bestandsdescriptor teruggestuurd naar de server. Dit geeft aan dat het bestand is geopend.

Gewoonlijk werkt een aangepast proces niet met bestandsdescriptors. Bestandsbeschrijvingen worden uitgewisseld tussen een NFS-client en een NFS-server. In versie 2 van NFS is de bestandsdescriptor 32 bytes en in versie 3 is deze gegroeid tot 64 bytes.

De client gebruikt het NFS-aankoppelprotocol om het bestandssysteem van de server te koppelen voordat toegang wordt verkregen tot NFS-bestanden. Dit gebeurt meestal wanneer de client opstart. Als resultaat ontvangt de client een bestandsdescriptor voor het bestandssysteem van de server.

Afbeelding 29.5 beschrijft de volgorde van acties voor een Unix-client bij het uitvoeren van de opdracht mount (8).

Afbeelding 29.5 Mount-protocol gebruikt door de Unix mount-opdracht.

In dit geval worden de volgende stappen uitgevoerd.

1. Wanneer de server opstart, start de poortconverter erop.
2. Na de port mapper start de mount daemon (mountd) op de server. Het creëert een TCP-eindpunt en een UDP-eindpunt en wijst aan elk een dynamisch toegewezen poortnummer toe. Vervolgens registreert het deze nummers bij de poortmapper.
3. De client voert het mount-commando uit, dat een RPC-aanroep doet naar de poortmapper van de server om het poortnummer van de mount-daemon op de server te krijgen. Zowel TCP als UDP kunnen worden gebruikt voor communicatie tussen de client en de poortmapper, maar meestal wordt UDP gebruikt.
4. De port mapper rapporteert het poortnummer.
5. De opdracht mount stuurt een RPC-aanroep naar de mount-daemon om het bestandssysteem van de server te koppelen. Nogmaals, zowel TCP als UDP kunnen worden gebruikt, maar meestal wordt UDP gebruikt. De server kan nu de "geldigheid" van de client controleren op basis van zijn IP-adres en poortnummer om te zien of deze client het gespecificeerde bestandssysteem kan aankoppelen.
6. De mount-daemon reageert met een bestandsdescriptor voor het opgegeven bestandssysteem.
7. De client mount-opdracht geeft de mount-systeemaanroep om de bestandsdescriptor die in stap 5 is verkregen te binden aan het lokale koppelpunt op de clienthost. De bestandsdescriptor wordt opgeslagen in de NFS-clientcode en vanaf dit punt zal elke toegang door gebruikersprocessen tot bestanden op het bestandssysteem van de server de bestandsdescriptor als uitgangspunt gebruiken.

Een dergelijke implementatie delegeert het hele mount-proces, behalve de mount-systeemaanroep op de client, aan gebruikersprocessen, niet aan de kernel. De drie programma's die we lieten zien - het mount-commando, de port mapper en de mount-daemon - zijn gebruikersprocessen.

In dit voorbeeld werd op host sun (NFS-client) de opdracht uitgevoerd

Dit commando koppelt de /usr-map op de host bsdi (NFS-server) als het lokale bestandssysteem /nfs / bsdi /usr. Figuur 29.6 toont het resultaat.

Afbeelding 29.6 De bsdi: /usr-map aankoppelen als /nfs / bsdi /usr op sun.

Als dan het bestand /nfs/bsdi/usr/rstevens/hello.c op de sun-client wordt geopend, wordt het bestand /usr/rstevens/hello.c geopend op de bsdi-server.

De NFS-server biedt 15 procedures, die we nu zullen beschrijven. (De nummers die in de beschrijving worden gebruikt, komen niet overeen met de NFS-procedurenummers, omdat we ze per functie hebben gegroepeerd.) Hoewel NFS is ontworpen om te werken tussen verschillende besturingssystemen, niet alleen Unix-systemen, zijn sommige procedures gebaseerd op Unix-functionaliteit, die op hun beurt mogelijk niet worden ondersteund door andere besturingssystemen (bijvoorbeeld harde koppelingen, symbolische koppelingen, groepering, uitvoeringsmachtigingen, enzovoort). Hoofdstuk 4 bevat meer informatie over de kenmerken van bestandssystemen, waarvan sommige door NFS worden gebruikt.

1. KRIJGEN. Retourneert bestandskenmerken: bestandstype (normaal bestand, directory, enzovoort), toegangsrechten, bestandsgrootte, bestandseigenaar, laatste toegangstijd, enzovoort.
2. SETAT. Stelt de attributen van een bestand in. Er kan slechts een bepaalde set attributen worden ingesteld: toegangsrechten, eigenaar, groepseigendom, grootte, tijdstip van laatste toegang en tijdstip van laatste wijziging.
3. STATFS. Retourneert de status van het bestandssysteem: vrije ruimte, optimale overdrachtsgrootte, enzovoort. Wordt bijvoorbeeld gebruikt door het Unix df-commando.
4. OPZOEKEN. "Evalueert" het bestand. Deze procedure wordt door de client aangeroepen telkens wanneer een gebruikersproces een bestand opent dat zich op de NFS-server bevindt. De bestandsdescriptor wordt geretourneerd, samen met de bestandskenmerken.
5. LEZEN. Leest uit een bestand. De client specificeert de bestandsdescriptor, de startbyte-offset en het maximale aantal te lezen bytes (tot 8192).
6. SCHRIJVEN. Schrijft naar een bestand. De client specificeert de bestandsdescriptor, de startbyte-offset, het aantal te schrijven bytes en de te schrijven gegevens.

   NFS-schrijfbewerkingen moeten synchroon zijn (in behandeling). De server kan niet met OK antwoorden totdat de gegevens met succes naar de schijf zijn geschreven (en alle andere bestandsinformatie die moet worden bijgewerkt).

7. CREËREN. Maakt een bestand aan.
8. VERWIJDEREN. Verwijdert het bestand.
9. HERnoemen. Hernoemt het bestand.
10. KOPPELING. Maakt een harde link naar een bestand. Een harde link is een Unix-concept dat specificeert dat een bepaald bestand op schijf een willekeurig aantal toegangspunten (namen, ook wel harde links genoemd) kan hebben die naar dat bestand verwijzen.
11. SYMLINK. Creëert een symbolische link naar het bestand. Een symbolische link is een bestand dat de naam van een ander bestand bevat. De meeste bewerkingen die worden uitgevoerd op een symbolische link (bijvoorbeeld openen) worden daadwerkelijk uitgevoerd op het bestand waarnaar de symbolische link verwijst.
12. LEES LINK. Het lezen van een symbolische link retourneert de naam van het bestand waarnaar wordt verwezen door de symbolische link.
13. MKDIR. Maakt een map aan.
14. RMDIR. Verwijdert een map.
15. LEZEN. Leest een directory. Wordt bijvoorbeeld gebruikt door het Unix ls-commando.

In feite beginnen de bovenstaande procedurenamen met het voorvoegsel NFSPROC_, dat we hebben weggelaten.

NFS is oorspronkelijk geschreven om UDP te gebruiken en alle leveranciers bieden deze mogelijkheid. Nieuwere implementaties ondersteunen echter ook TCP. TCP-ondersteuning wordt gebruikt om op steeds snellere wereldwijde netwerken te werken. Daarom is het gebruik van NFS niet langer beperkt tot lokale netwerken.

De grenzen tussen lokale en mondiale netwerken vervagen en dat gaat allemaal heel snel. Retourtijden variëren over een zeer breed bereik en overlopen komen steeds vaker voor. Deze kenmerken van wide area-netwerken leiden ertoe dat ze in toenemende mate de algoritmen gebruiken die we voor TCP hebben overwogen - langzame start en congestie vermijden. Aangezien UDP niets biedt dat lijkt op deze algoritmen, moeten ze of iets dergelijks worden ingebouwd in de NFS-client en -server, anders moet TCP worden gebruikt.

De Berkeley Net/2 NFS-implementatie ondersteunt zowel UDP als TCP. [Macklem 1991] beschrijft deze implementatie. Laten we eens kijken hoe NFS verschilt van TCP.

1. Wanneer de server opstart, start hij de NFS-server, die een actieve opening doet op TCP-poort 2049, wachtend op een verbindingsverzoek van de client. Dit wordt meestal gedaan naast de normale NFS UDP, die luistert naar inkomende datagrammen op UDP-poort 2049.
2. Wanneer een client het bestandssysteem van de server koppelt met behulp van TCP, wordt er actief geopend op TCP-poort 2049 op de server. Dit brengt een TCP-verbinding tot stand tussen de client en de server voor dit bestandssysteem. Als dezelfde client een ander bestandssysteem op dezelfde server koppelt, wordt een andere TCP-verbinding gemaakt.
3. Zowel de client als de server stellen de TCP keepalive-optie in aan hun uiteinden van de verbinding (hoofdstuk 23). Hiermee kunt u het moment van falen of herstarten van een of andere deelnemer aan de centrale bepalen.
4. Alle toepassingen op de client die het bestandssysteem van de server gebruiken, delen dezelfde TCP-verbinding voor dat bestandssysteem. Als het bijvoorbeeld in figuur 29.6 stond, zou er een andere map op bsdi zijn met de naam smith onder de map / usr, die toegang heeft tot bestanden in / nfs / bsdi / usr / rstevens en / nfs / bsdi / usr / smith zou er een delen en de dezelfde zelfde TCP-verbinding.
5. Als de client vaststelt dat de server is gecrasht of opnieuw is opgestart (na het ontvangen van een TCP-fout "time-out verbinding" of "verbinding gesloten door host"), probeert hij opnieuw verbinding te maken met de server. De client maakt een andere actief open om een ​​TCP-verbinding voor dit bestandssysteem opnieuw tot stand te brengen. Elk verzoek van een client die een time-out heeft gehad op een eerdere verbinding, wordt opnieuw uitgegeven op een nieuwe verbinding.
6. Als een client crasht, gebeurt hetzelfde met applicaties die vóór de crash draaiden. Wanneer de client opnieuw opstart, zal het waarschijnlijk het bestandssysteem van de server opnieuw activeren met behulp van TCP, met een andere TCP-verbinding met de server. De vorige client-server-verbinding voor dit bestandssysteem is in een halfopen staat (de server denkt dat deze nog open is), maar aangezien de server de optie "keep alive" heeft ingesteld, wordt deze halfopen verbinding gesloten wanneer de De TCP-server stuurt de volgende sonde. "blijf in leven."

Na verloop van tijd zijn andere leveranciers van plan om NFS via TCP te gaan ondersteunen.

Laten we tcpdump gebruiken om te zien welke NFS-routines door de client worden aangeroepen voor normale bestandsbewerkingen. Wanneer tcpdump vaststelt dat een UDP-datagram een ​​RPC-aanroep bevat (aanroep is 0 in figuur 29.1) met bestemmingspoort 2049, decodeert het het datagram als een NFS-verzoek. Evenzo, als een UDP-datagram een ​​RPC-antwoord bevat (antwoord is 1 in figuur 29.2) met een bronpoort van 2049, decodeert het het datagram als een NFS-antwoord.

In het eerste voorbeeld zullen we het bestand, dat zich op de NFS-server bevindt, naar de terminal kopiëren met het commando cat (1):

Zon% cat /nfs/bsdi/usr/rstevens/hello.c kopieer bestand naar terminal
voornaamst ()
{
printf ("hallo, wereld \ n");
}

Het / nfs / bsdi / usr bestandssysteem op sun (NFS-client) is eigenlijk het / usr bestandssysteem op bsdi (NFS-server), zoals weergegeven in figuur 29.6. De zonnekernel detecteert dit wanneer cat een bestand opent en NFS gebruikt om toegang te krijgen tot het bestand. Afbeelding 29.7 toont de uitvoer van de opdracht tcpdump.

1 0.0 sun.7aa6> bsdi.nfs: 104 getattr
2 0.003587 (0.0036) bsdi.nfs> sun.7aa6: antwoord ok 96

3 0.005390 (0.0018) sun.7aa7> bsdi.nfs: 116 lookup "rstevens"
4 0.009570 (0.0042) bsdi.nfs> sun.7aa7: antwoord ok 128

5 0.011413 (0.0018) sun.7aa8> bsdi.nfs: 116 lookup "hello.c"
6 0.015512 (0.0041) bsdi.nfs> sun.7aa8: antwoord ok 128

7 0.018843 (0.0033) zo.7aa9> bsdi.nfs: 104 getattr
8 0.022377 (0.0035) bsdi.nfs> sun.7aa9: antwoord ok 96

9 0.027621 (0.0052) sun.7aaa> bsdi.nfs: 116 gelezen 1024 bytes @ 0
10 0.032170 (0.0045) bsdi.nfs> sun.7aaa: antwoord ok 140

Afbeelding 29.7 NFS-bewerking bij het lezen van een bestand.

De opdracht tcpdump decodeert een NFS-verzoek of -antwoord en drukt het XID-veld voor de client af in plaats van het poortnummer. Het XID-veld op regel 1 en 2 is 0x7aa6.

De bestandsnaam /nfs/bsdi/usr/rstevens/hello.c wordt met één element tegelijk afgehandeld door de open-functie in de client-kernel. Wanneer de open-functie / nfs / bsdi / usr bereikt, detecteert deze dat dit een NFS-koppelpunt is.

Op regel 1 roept de client de GETATTR-procedure aan om de attributen te krijgen van de serverdirectory die de client heeft aangekoppeld (/usr). Dit RPC-verzoek bevat 104 bytes aan gegevens, naast de IP- en UDP-headers. Het antwoord op regel 2 retourneert OK en bevat 96 bytes aan gegevens, naast de IP- en UDP-headers. We kunnen in deze figuur zien dat het kleinste NFS-bericht ongeveer 100 bytes aan gegevens bevat.

Op regel 3 roept de client LOOKUP aan op het rstevens-bestand en ontvangt een OK-antwoord op regel 4. LOOKUP specificeert de naam van het rstevens-bestand en een bestandsdescriptor die door de kernel werd opgeslagen toen het externe bestandssysteem werd aangekoppeld. Het antwoord bevat een nieuwe bestandsdescriptor die in de volgende stap wordt gebruikt.

Op regel 5 LOOKUP de client het bestand hello.c met behulp van de bestandsdescriptor van regel 4. Het krijgt een andere bestandsdescriptor op regel 6. Deze nieuwe bestandsdescriptor is precies wat de client op regel 7 en 9 gebruikt om toegang te krijgen tot de / nfs bestand /bsdi/usr/rstevens/hello.c. We zien dat de client een LOOKUP uitvoert op elke naamcomponent in het pad naar het bestand dat wordt geopend.

Op regel 7 voert de client GETATTR opnieuw uit, gevolgd door een READ op regel 9. De client vraagt ​​1024 bytes aan vanaf offset 0, maar ontvangt minder dan 1024 bytes aan gegevens. (Na het aftrekken van de RPC-veldgroottes en andere waarden die worden geretourneerd door de READ-procedure, worden 38 bytes aan gegevens geretourneerd op regel 10. Dat is precies de grootte van het hello.c-bestand.)

In dit voorbeeld is het gebruikersproces niet op de hoogte van deze NFS-verzoeken en antwoorden die door de kernel worden gedaan. De applicatie roept gewoon de kernel open-functie aan, die de uitwisseling van 3 verzoeken en 3 reacties oproept (regels 1-6), en roept vervolgens de kernel-leesfunctie aan, die 2 verzoeken en 2 reacties oproept (regels 7-10). Voor de clienttoepassing is het bestand dat zich op de NFS-server bevindt transparant.

Laten we als een ander voorbeeld de werkdirectory wijzigen in de directory op de NFS-server en dan een nieuwe directory maken:

Zon% cd / nfs / bsdi / usr / rstevens werkmap wijzigen
zon% mkdir Mail maak een map aan

Afbeelding 29.8 toont de uitvoer van het tcpdump-commando.

1 0.0 sun.7ad2> bsdi.nfs: 104 getattr
2 0.004912 (0.0049) bsdi.nfs> sun.7ad2: antwoord ok 96

3 0.007266 (0.0024) zo.7ad3> bsdi.nfs: 104 getattr
4 0.010846 (0.0036) bsdi.nfs> sun.7ad3: antwoord ok 96

5 35.769875 (35.7590) zo.7ad4> bsdi.nfs: 104 getattr
6 35.773432 (0.0036) bsdi.nfs> sun.7ad4: antwoord ok 96

7 35.775236 (0.0018) sun.7ad5> bsdi.nfs: 112 opzoeken "Mail"
8 35.780914 (0.0057) bsdi.nfs> sun.7ad5: antwoord ok 28

9 35.782339 (0.0014) sun.7ad6> bsdi.nfs: 144 mkdir "Mail"
10 35.992354 (0.2100) bsdi.nfs> sun.7ad6: antwoord ok 128

Afbeelding 29.8 NFS-bewerking door directory (cd) te wijzigen in NFS-directory en vervolgens directory (mkdir) aan te maken.

Bij het wisselen van directory roept de client de GETATTR-procedure twee keer aan (regel 1-4). Wanneer we een nieuwe map maken, roept de client de GETATTR-procedure aan (regel 5 en 6), dan LOOKUP (regel 7 en 8 om te controleren of een dergelijke map niet bestaat), en vervolgens MKDIR om de map te maken (regel 9 en 10) . Een OK-antwoord op regel 8 betekent niet dat de directory bestaat. Het betekent gewoon dat de procedure een bepaalde waarde heeft geretourneerd. tcpdump interpreteert de waarde die wordt geretourneerd door NFS-routines niet. De opdracht drukt eenvoudigweg OK en het aantal bytes aan gegevens in het antwoord af.

Een van de kenmerken van NFS (NFS-critici noemen dit een wrat, geen kenmerk) is dat de NFS-server onverschillig is. Het maakt de server niet uit welke clients welke bestanden openen. Merk op dat er geen open- of sluitprocedure is in de eerder getoonde lijst met NFS-procedures. LOOKUP lijkt op openen, maar de server weet nooit of de client het bestand heeft geopend nadat de LOOKUP is gemaakt.

De reden voor dit "luie gedrag" is om het gemakkelijker te maken om te herstellen van een servercrash en opnieuw op te starten.

In het volgende voorbeeld lezen we een bestand van een NFS-server wanneer de server crasht en opnieuw opstart. Dit laat zien hoe de "onverschilligheid" van de server ervoor zorgt dat de client "niet weet" dat de server niet beschikbaar is. Zolang de server crasht en opnieuw opstart, is de client zich niet bewust van het probleem en werkt de clienttoepassing hetzelfde als voorheen.

Op de sun-client begonnen we cat met een heel groot bestand als argument (/ usr / share / lib / termcap op de svr4 NFS-server), ontkoppelden we de Ethernet-kabel tijdens de overdracht, schakelden we de server uit en herstartten we de kabel. De client is geconfigureerd om 1.024 bytes te lezen in een enkele NFS-lezing. Figuur 29.9 toont de uitvoer van tcpdump.

Regels 1-10 komen overeen met de client die het bestand opent. Deze bewerking lijkt op die in figuur 29.7. Op regel 11 zien we de eerste read (READ) uit een bestand van 1024 bytes aan gegevens; het antwoord keerde terug op regel 12. Dit gaat door tot regel 129 (lees een 1024 byte LEZEN en vervolgens een OK-antwoord).

Op regel 130 en 131 zien we twee verzoeken met een time-out en opnieuw verzonden op regel 132 en 133. Eerste vraag: we zien twee leesverzoeken, de ene begint bij offset 65536 en de andere begint bij offset 73728, waarom? De clientkernel stelde vast dat de clienttoepassing sequentieel aan het lezen was en probeerde de datablokken van tevoren te krijgen. (De meeste Unix-kernels doen dit read-ahead.) De client-kernel voert ook verschillende NFS-blok I/O-daemons (biod-processen) uit die namens de client meerdere RPC-verzoeken proberen te genereren. Eén daemon leest 8192 bytes vanaf 65536 (in 1024-byte ketens), terwijl andere 8192 bytes vooruit lezen vanaf 73728.

Client-hertransmissies verschijnen op regel 130-168. Op regel 169 zien we dat de server opnieuw is opgestart en een ARP-verzoek heeft verzonden voordat wordt gereageerd op het NFS-verzoek van de client vanaf regel 168. Het antwoord op regel 168 wordt verzonden op regel 171. De READ-verzoeken van de client gaan door.

1 0.0 sun.7ade> svr4.nfs: 104 getattr
2 0.007653 (0.0077) svr4.nfs> sun.7ade: antwoord ok 96

3 0.009041 (0.0014) sun.7adf> svr4.nfs: 116 lookup "share"
4 0.017237 (0.0082) svr4.nfs> sun.7adf: antwoord ok 128

5 0.018518 (0.0013) sun.7ae0> svr4.nfs: 112 opzoeken "lib"
6 0.026802 (0.0083) svr4.nfs> sun.7ae0: antwoord ok 128

7 0.028096 (0.0013) sun.7ae1> svr4.nfs: 116 lookup "termcap"
8 0.036434 (0.0083) svr4.nfs> sun.7ae1: antwoord ok 128

9 0.038060 (0.0016) zon.7ae2> svr4.nfs: 104 getattr
10 0.045821 (0.0078) svr4.nfs> sun.7ae2: antwoord ok 96

11 0.050984 (0.0052) sun.7ae3> svr4.nfs: 116 lezen 1024 bytes @ 0
12 0.084995 (0.0340) svr4.nfs> sun.7ae3: antwoord ok 1124

Lezing

128 3.430313 (0.0013) sun.7b22> svr4.nfs: 116 gelezen 1024 bytes @ 64512
129 3.441828 (0.0115) svr4.nfs> sun.7b22: antwoord ok 1124

130 4.125031 (0.6832) zo.7b23>
131 4.868593 (0.7436) zo.7b24>

132 4.993021 (0.1244) sun.7b23> svr4.nfs: 116 lees 1024 bytes @ 65536
133 5.732217 (0.7392) sun.7b24> svr4.nfs: 116 lees 1024 bytes @ 73728

134 6.732084 (0,9999) sun.7b23> svr4.nfs: 116 lezen 1024 bytes @ 65536
135 7.472098 (0.7400) sun.7b24> svr4.nfs: 116 lees 1024 bytes @ 73728

136 10.211964 (2.7399) zo.7b23>
137 10.951960 (0.7400) zo.7b24>

138 17.171767 (6.2198) sun.7b23> svr4.nfs: 116 lees 1024 bytes @ 65536
139 17.911762 (0.7400) sun.7b24> svr4.nfs: 116 lees 1024 bytes @ 73728

140 31.092136 (13.1804) sun.7b23> svr4.nfs: 116 lees 1024 bytes @ 65536
141 31.831432 (0.7393) sun.7b24> svr4.nfs: 116 lees 1024 bytes @ 73728

142 51.090854 (19.2594) sun.7b23> svr4.nfs: 116 lezen 1024 bytes @ 65536
143 51.830939 (0.7401) sun.7b24> svr4.nfs: 116 lees 1024 bytes @ 73728

144 71.090305 (19.2594) sun.7b23> svr4.nfs: 116 gelezen 1024 bytes @ 65536
145 71.830155 (0.7398) sun.7b24> svr4.nfs: 116 lees 1024 bytes @ 73728

Heruitzendingen

167 291.824285 (0.7400) sun.7b24> svr4.nfs: 116 lees 1024 bytes @ 73728
168 311.083676 (19.2594) sun.7b23> svr4.nfs: 116 gelezen 1024 bytes @ 65536

Server opnieuw opgestart

169 311.149476 (0.0658) arp wie-heeft zon vertellen svr4
170 311.150004 (0.0005) arp antwoord zon is-om 8: 0: 20: 3: f6: 42

171 311.154852 (0.0048) svr4.nfs> sun.7b23: antwoord ok 1124

172 311.156671 (0.0018) sun.7b25> svr4.nfs: 116 gelezen 1024 bytes @ 66560
173 311.168926 (0.0123) svr4.nfs> sun.7b25: antwoord ok 1124
lezing

Figuur 29.9 Een client las een bestand toen de NFS-server crashte en herstartte.

De clienttoepassing zal nooit weten dat de server is gecrasht en opnieuw is opgestart, behalve dat er een pauze van 5 minuten was tussen regel 129 en 171, dus de servercrash is transparant voor de client.

Om de lengte van de hertransmissie-time-outs in dit voorbeeld te schatten, stelt u zich voor dat er twee client-daemons zijn, elk met hun eigen time-outs. De intervallen voor de eerste daemon (afgelezen vanaf offset 65536) zijn ruwweg de volgende (afgerond op twee decimalen): 0,68; 0,87; 1,74; 3,48; 6,96; 13,92; 20,0; 20,0; 20.0 enzovoort. De afstand voor de tweede daemon (aflezing van offset 73728) is precies hetzelfde. Dit betekent dat deze NFS-clients time-outs gebruiken die veelvouden zijn van 0,875 seconden met een bovengrens van 20 seconden. Na elke time-out wordt het hertransmissie-interval verdubbeld: 0,875; 1,75; 3,5; 7.0 en 14.0.

Hoe lang zal de klant hertransmissies maken? De opdrachtgever heeft twee mogelijkheden die hierop van invloed kunnen zijn. Ten eerste, als het bestandssysteem van de server hard is gemount, zal de client voor altijd opnieuw verzenden, maar als het bestandssysteem van de server soft is gemount, zal de client het afbreken na een vast aantal hertransmissies. In het geval van een harde koppeling heeft de client ook een optie om de gebruiker toe te staan ​​mislukte hertransmissies af te breken of niet. Als de clienthost bij het koppelen van het bestandssysteem van de server aangeeft dat het mogelijk is om te onderbreken en als we geen 5 minuten willen wachten voordat de server opnieuw is opgestart na een storing, kunnen we het onderbrekingsteken invoeren om de clienttoepassing te beëindigen .

RPC-procedures kunnen meerdere keren door de server worden uitgevoerd, maar ze geven nog steeds hetzelfde resultaat. Bijvoorbeeld een NFS-leesroutine. Zoals we in figuur 29.9 hebben gezien, voert de client de READ-oproep gewoon opnieuw uit totdat hij een reactie ontvangt. In ons voorbeeld was de reden voor de hertransmissie dat de server uitviel. Als de server niet faalde en de berichten met de RPC-antwoorden verloren zijn gegaan (aangezien UDP geen betrouwbaar protocol is), verzendt de client gewoon opnieuw en voert de server dezelfde READ opnieuw uit. Hetzelfde deel van hetzelfde bestand wordt opnieuw gelezen en naar de klant gestuurd.

Dit werkt omdat elke READ een startoffset bevat. Als de NFS-procedure de server zou vragen om de volgende N bytes van het bestand te lezen, zou het niet werken. Als de server niet onverschillig was (deze waarde is het tegenovergestelde van onverschilligheid), en het antwoord is verloren, en de client geeft READ opnieuw uit voor de volgende N bytes, dan zal het resultaat anders zijn. Daarom hebben NFS-procedures LEZEN en SCHRIJVEN een startoffset. Het is de client die de status handhaaft (de huidige offset voor elk bestand), niet de server.

Helaas kunnen niet alle bestandssysteembewerkingen meerdere keren worden uitgevoerd. Stel je bijvoorbeeld de volgende stappen voor: de NFS-client geeft een REMOVE-verzoek om een ​​bestand te verwijderen; De NFS-server verwijdert het bestand en reageert met OK; serverreactie gaat verloren; NFS-client time-out en verzendt het verzoek opnieuw; De NFS-server kan het bestand niet vinden en geeft een foutmelding; de clienttoepassing ontvangt een foutmelding dat het bestand niet bestaat. Deze fout wordt geretourneerd naar de clienttoepassing en deze fout bevat onjuiste informatie - het bestand bestond niet en is verwijderd.

Hieronder vindt u een lijst met NFS-routines die meerdere keren kunnen worden uitgevoerd: GETATTR, STATFS, LOOKUP, READ, WRITE, READLINK en READDIR. Procedures die niet meerdere keren kunnen worden uitgevoerd: CREATE, REMOVE, RENAME, LINK, SYMLINK, MKDIR en RMDIR. SETATTR wordt meestal meerdere keren uitgevoerd, tenzij het werd gebruikt om het bestand af te kappen.

Aangezien er altijd antwoorden verloren kunnen gaan bij het gebruik van UDP, moeten NFS-servers een manier hebben om bewerkingen af ​​te handelen die niet meerdere keren kunnen worden uitgevoerd. De meeste servers hebben een recente responscache waarin ze de laatst ontvangen reacties voor dergelijke bewerkingen opslaan. Elke keer dat de server een verzoek ontvangt, kijkt hij eerst door zijn cache, en als een overeenkomst wordt gevonden, retourneert hij het vorige antwoord in plaats van de NFS-procedure opnieuw aan te roepen. [Juszczak 1989] beschrijft de details van deze cachetypes.

Een vergelijkbare benadering van procedures op servers is van toepassing op alle op UDP gebaseerde toepassingen, niet alleen op NFS. DNS biedt bijvoorbeeld een service die meerdere keren pijnloos wordt gebruikt. De DNS-server kan een willekeurig aantal keren een parserverzoek indienen, wat niet tot negatieve resultaten zal leiden (misschien, behalve dat netwerkbronnen bezet zijn).

In 1994 werden specificaties voor versie 3 van het NFS-protocol vrijgegeven [Sun Microsystems 1993]. De implementaties zullen naar verwachting in 1994 beschikbaar komen.

De belangrijkste verschillen tussen versie 2 en versie 3 worden hier kort beschreven, we zullen ze V2 en V3 noemen.

1. Bestandsbeschrijvingen in V2 zijn een array van vaste grootte van 32 bytes. In V3 is dit een array met variabele grootte tot 64 bytes. Een array met variabele lengte in XDR wordt gedefinieerd door een 4-byte-teller gevolgd door echte bytes. Dit verkleint de bestandsdescriptor in implementaties zoals Unix, die slechts ongeveer 12 bytes nodig hebben, maar laat niet-Unix-implementaties toe om aanvullende informatie uit te wisselen.
2. V2 beperkt het aantal bytes per READ of WRITE RPC tot 8192 bytes. Deze beperking is niet van toepassing in V3, wat op zijn beurt betekent dat bij gebruik van UDP de beperking alleen in de grootte van het IP-datagram ligt (65535 bytes). Hierdoor kunnen grote pakketten worden gebruikt bij het lezen en schrijven op snelle netwerken.
3. Bestandsgroottes en initiële byte-offsets voor LEES- en SCHRIJF-routines zijn uitgebreid van 32 naar 64 bits om grotere bestanden te kunnen opnemen.
4. Bij elke aanroep worden bestandskenmerken geretourneerd die van invloed kunnen zijn op de kenmerken. Dit vermindert het aantal GETATTR-oproepen dat de klant nodig heeft.
5. Schrijven (WRITE) kan asynchroon zijn, terwijl ze in V2 synchroon moesten zijn. Dit kan de prestaties van de SCHRIJF-procedure verbeteren.
6. Eén procedure werd verwijderd (STATFS) en zeven werden toegevoegd: ACCESS (controleren van bestandspermissies), MKNOD (maken van een speciaal Unix-bestand), READDIRPLUS (retourneert de namen van bestanden in een directory samen met hun attributen), FSINFO (geeft statistische informatie over het bestandssysteem ), FSSTAT (retourneert dynamische bestandssysteeminformatie), PATHCONF (retourneert POSIX.1-bestandsinformatie) en COMMIT (transfert eerder gemaakte asynchrone schrijfbewerkingen naar permanente opslag).

RPC is een manier om een ​​client-server applicatie zo te bouwen dat de client simpelweg procedures op de server aanroept. Alle netwerkdetails zijn verborgen in client- en serverstubs, die voor toepassingen worden gegenereerd door het RPC-pakket en in de RPC-bibliotheekroutines. We lieten het RPC-oproep- en responsberichtformaat zien en vermeldden dat XDR wordt gebruikt om waarden te coderen, waardoor RPC-clients en -servers op machines met verschillende architecturen kunnen draaien.

Een van de meest gebruikte RPC-applicaties is Sun NFS, een heterogeen bestandstoegangsprotocol dat veel wordt gebruikt op hosts van bijna alle formaten. We hebben NFS besproken en hoe het UDP of TCP gebruikt. NFS Versie 2 definieert 15 procedures.

Clienttoegang tot de NFS-server begint met een mount-log, waarna een bestandsdescriptor naar de client wordt teruggestuurd. De client heeft dan toegang tot bestanden op het bestandssysteem van de server met behulp van deze bestandsdescriptor. Bestandsnamen worden met één element van de naam tegelijk op de server opgezocht en voor elk element wordt een nieuwe bestandsdescriptor geretourneerd. Het eindresultaat is een handvat voor het bestand dat is geopend en gebruikt voor sequentiële lees- en schrijfbewerkingen.

NFS probeert al zijn procedures onafhankelijk te maken van het aantal uitvoeringen, zodat de client het verzoek eenvoudig opnieuw kan indienen als het antwoord verloren gaat. We hebben hiervan voorbeelden gezien: in het geval dat een client een bestand aan het lezen was terwijl de server crashte en opnieuw opstartte.

Opdrachten