SPECIFICATIILE PROTOCOLULUI TELNET Acest RFC specifica un standard pentru comunitatea Internet ARPA. Se asteapta ca gazdele din Internetul ARPA sa adopte si sa implementeze acest standard. INTRODUCERE Scopul protocolului TELNET este de a oferi facilitati generale, bi-directionale, orientate pe octeti de opt biti. Scopul sau primar este de a permite o metoda standard de interfata intre dispozitivele de terminal si procesele orientate pe rularea intr-un terminal. Se asteapta ca protocolul sa fie folositsi pentru comunicarea terminal-terminal ("legatura") si comunicarea proces-proces (calcul distribuit). CONSIDERATII GENERALE O conexiune TELENT este o conexiune TCP (Transmission Control Protocol - Protocol de control al transmiterii) utilizata la transmiterea de date, continanad in plus informatii de control TELNET. Protocolul TELNET este constriut pe trei idei principale: prima, conceptului "terminalului virtual de retea"; a doua, principiul optiunilor negociate; si a treia, o vedere simetrica a terminalelor si proceselor. 1. Cand este stabilita pentru prima oara o conexiune TELNET, fiecare capat se presupune ca incepe sau se termina intr-un "Terminal virtual de retea" (NVT - "Network Virtual Terminal"). Un NVT este un dispozitiv imaginar care ofera o reprezentare standard, pentru toate retelele, intermediara a unui terminal canonic. Acesta elimina necesitatea ca gazdele "server" sau "utilizator" sa pastreze informatii despre caracteristicile terminalelor fiecareia si conventiile manevrarii teminalelor. Toate gazdele, atat utilizator cat si server, isi mapeaza caracteristicile locale ale dispozitivelor si conventiilor asa incat aparent sa para ca interactioneaza cu un NVT din retea, si fiecare presupune ca acelasi lucru se intampla si la partenerii lor de comunicatie. NVT-ul intentioneaza sa echilibreze tendinta de a fi prea restricitv (neacordand gazdelor un vocabular destul de bogat pentru maparea locala a caracterisitcilor proprii), si de a fi prea intelegator (penalizand utilizatorii cu terminale modeste). NOTA: Gazda "utilizator" este gazda careia ii este atasata in mod normal terminalul fizic, si gazda "server" esete cea care de obicei acorda anumite servicii. Ca un punct de vedere alternativ, Postel & Reynolds [Page 1] RFC 854 May 1983 aplicabil chiar si in comunicatiile terminal-terminal sau proces-proces, gazda "utilizator" este cea care initiaza comunicarea. 2. Principiul otiunilor negociate ia in considerare faptul ca multe gazde vor dori sa acorde servicii suplimentare pe langa cele existente prin NVT, si multi utilizatori vor avea terminale sofisticate si vor dori servicii elegante in locul unora minimale. Independente, dar structurate in cadrul protocolului TELNET, sunt cateva "optiuni" ce vor fi sanctionate si pot fi folosite precedate de structura "FA (ceva), Nu proceda astfel" etc (descrisa mai jos) pentru a permite serverului si utilizatorului sa cada de acord asupra utilizarii unui set de conventii mai elaborate (sau poate doar diferite) in conexiunea lor TELNET. Asemenea optiuni pot include schimbarea setului de caractere, modul de ecou, etc. Strategia de baza pentru setarea utilizarii acestor optiuni este ca macar unul dintre partenerii conexiunii sa initieze o cerere pentru ca unele otiuni sa aiba efect. Celalalt partener va accepta sau refuza apoi cererea. Daca cererea este acceptata, atunci optiunea va avea efect imediat; daca este refuzata, aspectul conexiunii ramane cel specific unui NVT. In mod sigur unul din parteneri poate oricand refuza o cerere sau sa ceara activarea unei optiuni, si nu va refuza niciodata o cerere de dezactivare anumite optiuni de vreme ce toti partenerii trebuie sa fie pregatiti sa suporte NVT. Sintaxa negocierii optiunilor a fost conceputa astfel incat daca ambii parteneri fac o cerere simultan, fiecare vor vedea cererea celuilalt ca o confirmare pozitiva a celei proprii. 3. Simetria sintaxei de negociere poate duce uneori la bucle infinite de confirmari -- fiecare partener vazand comenzile venite nu ca niste confirmari, ci ca noi cereri care trebuie confirmate. Pentru a preveni astfel de bucle, primeaza urmatoarele reguli: a. Partenerii pot doar sa ceara o schimbare in starea optiunilor; astfel, unul din ei nu va putea sa trimta o cerere doar pentru a anunta ce setari are. b. Daca un partener primeste ceea ce pare a fi o cerere de a intra intr-un mod in care deja se afla, cererea nu va fi confirmata. Acest non-raspuns este important pentru a preveni bucle infinite in negociere. Este necesar ca un raspuns sa fie trimis cererilor de schimbare a modului -- chiar daca modul nu este practic schimbat. c. Oricand unul din parteneri trimite o comanda optiune celuilat partener, fie ca o carere sau ca o confirmare, iar utilizarea optiunii va avea efect asupra procesarii datelor ce sunt trimise de la primul spre al doilea, atunci comanda va trebui introdusa in fluxul de date si indicat locul in care trebuie sa aiba efect. Postel & Reynolds [Page 2] RFC 854 May 1983 (Trebuie tinut cont ca va trece putin timp intre transmiterea unei cereri si primirea confirmarii, care poate fi si negativa. Astfel, o gazda poate opta pentru stocarea datelor intr-un buffer, dupa cererea unei optiuni, pana cand afla daca cererea a fost acceptata sau nu, pentru a ascunde perioada de "nesiguranta" de utilizator.) E posibil ca cererile pentru optiuni TELNET, deoarce fiecare partener incearca sa obtina cel mai bun serviciu de la celalalt. Inafara de aceasta, oricum, optiunile pot fi folosite pentru a modifica dinamic caracteristicile conexiunii pentru a se potrivi conditiilor locale. De exemplu, NVT-ul, asa cum se va explica mai tarziu, foloseste o disciplina de transmitere care se potriveste foarte bine numeroaselor aplicatii "cate o linie o data" cum ar fi BASIC, dar mai putin potrivite aplicatiilor "cate un caracter o data" cum ar fi NLS. Un server poate sa refuze aglomerarea procesorului necesara disciplinei "cate un caracter" cand aceasta este convenabil procesului local si va negocia o optiune potrivita. Oricum, in loc de a fi tot timpul asaltat de supraaglomerarea procesorului, ar putea comuta (negociind) spre NVT cand controlul detaliat nu mai este necesar.