FTN (de la FidoNet Technology Network ) este o tehnologie de rețea offline utilizată în Fido și Levnets .
FTN este o tehnologie care a apărut în rețeaua Fido în 1984, iar dezvoltarea tehnologiei a fost condusă de nevoile Fido în creștere rapidă. Cu toate acestea, este incorect să se identifice Fido și FTN, deoarece FTN poate fi folosit și pentru a crea alte rețele care ar putea să nu aibă legătură cu Fido în niciun fel. Astfel de rețele se numesc levnets . Cazuri cunoscute de utilizare a tehnologiilor FTN de către fidoshniks pentru organizarea de rețele industriale, înalt specializate.
Cea mai mare și mai complexă rețea FTN este FidoNet . În ea, adresarea se bazează pe afilierea geopolitică, iar viața rețelei este guvernată de o cartă . Stângii sunt de obicei mult mai simpli din punct de vedere organizațional.
Standardele după care este dezvoltat software-ul FTN sunt documentele adoptate de FTSC (Fido Network Technical Standards Committee), dar obligația de a respecta anumite documente în leftnets și Fido poate diferi.
Unitatea rețelei FTN este așa-numitul sistem - un set de programe configurate pentru a îndeplini funcții legate de redirecționarea și procesarea e-mailurilor și fișierelor. Persoana care întreține sistemul se numește operator de sistem ( sysop ). Fiecare sistem are o adresă.
Schema standard de adresare FTN este descrisă în FSP-1028 . Când este scrisă complet, adresa arată astfel: Zone:Net/Node.Point@Domain , unde primele patru câmpuri sunt completate cu numerele zonei, rețelei, nodului și, respectiv, punctului, iar al cincilea este desemnarea literei pentru rețeaua FTN. O astfel de înregistrare completă se numește înregistrare 5D. Formele scurte (4D, 3D și 2D) sunt, de asemenea, posibile - atunci când programele pot prelua valorile altor câmpuri.
Sistemele sunt nodale și punctuale. Diferența dintre ele constă de obicei doar în poziția juridică în rețea (de exemplu, în punctele Fido nu sunt în mod oficial membri ai rețelei). La prima vedere, adresa gazdei pare mai scurtă pentru că nu conține un număr după punct, dar de fapt este mereu prezentă, este pur și simplu zero în adresele gazdei și este de obicei omisă. În formă 5D, adresele nodurilor sunt de obicei scrise fără un număr de punct.
Câmpul „Domeniu” al unei adrese FTN (litera de rețea) nu trebuie confundat cu numele de domenii de Internet (consultați FQDN ). Astfel, numele de domeniu fidonet.org , care găzduiește site-ul oficial al rețelei Fido, nu va fi un domeniu valid atunci când este utilizat într-o adresă FTN. În schimb, ar trebui folosit doar fidonet .
Pot exista mai multe sisteme pe un computer. În primul rând, un set de programe poate fi configurat să funcționeze simultan sub mai multe adrese. Apoi se vorbește despre AKA (de la cunoscut și ca ) în plus față de adresa principală a sistemului (prima specificată în config ). În al doilea rând, pot exista mai multe kituri configurate să funcționeze independent. Acest lucru se întâmplă, de exemplu, atunci când un nod are o adresă de punct tehnic pentru funcționarea BBS sau a roboților .
Rețeaua este condusă de oficiali – coordonatori. Coordonatorii sunt responsabili pentru definirea schemelor de rutare și menținerea listei de noduri . O listă de noduri este o listă de sisteme de noduri care fac parte dintr-o rețea FTN. O listă de noduri conține informațiile necesare pentru ca un sistem să apeleze altul printr-o rețea publică. Sistemele de puncte pot accepta, de asemenea, conexiuni de intrare, informațiile pentru comunicarea cu acestea sunt introduse în lista de puncte .
Formatul listei de noduri și steagurile sunt descrise în FTS-5000 , FTS-5001 (standarde de bază) și FSP-1035 ( DNS Distributed Nodelist ). În Fido, steaguri valide sunt descrise și în epilogul listei de noduri. Formatul listei de puncte este descris în FTS-5002 .
Rețelele FTN au facilități pentru transferul de mesaje text și fișiere. Mesajele text pot fi împărțite în netmail (corespondență personală) și echomail (conferințe tematice publice). Instrumentele de partajare a fișierelor includ conferințe de ecou de fișiere (distribuirea fișierelor pe categorii tematice) și solicitări de fișiere (solicitarea unui anumit fișier de către un sistem de la altul). Cu toate acestea, mesajele text ale fișierelor codificate UUE sunt, de asemenea, obișnuite .
Multă vreme, rețelele FTN stabilesc limite pentru dimensiunea unui mesaj (de exemplu, regulile conferințelor cu ecou), din cauza imperfecțiunilor programelor utilizate în acel moment. Treptat au fost permise dimensiuni mai mari. limită imaginabilă a fost de 64 KB [1] programul proprietar FastEcho rămâne încă[ când? ] destul de popular pentru a nu putea face față mai mult [2] . Dar există o dezbatere plină de viață în Fido în aceste zile și tot mai mulți oameni se îndepărtează de ea în favoarea unor programe mai moderne, care nu au limite în ceea ce privește dimensiunea mesajelor.
Editorii de mesaje FTN existente nu acceptă Unicode și metodele de marcare. Acest lucru are ca rezultat transmiterea prin FTN numai a textului simplu, neformatat în CP866 sau în alt set de caractere codificat pe un singur octet . FTN vă permite să trimiteți mesaje în orice codificare care conține etichete de marcare, dar nu există editori care să le accepte.
Pentru a seta diferite caracteristici ale mesajului transmis, în el sunt introduse linii de control speciale - kludges , similar antetului RFC al mesajelor de e-mail . O descriere generală a kludge-urilor este conținută în FTS-4000 , dar kludge-urile în sine sunt descrise în documente separate. Fiecare mesaj trebuie să conțină codul MSGID ( FTS-0009 ), codificarea mesajului este indicată în kludge CHRS ( FTS -5003 ), mesajele criptate sau semnate EDS sunt indicate de kludge ENC ( FSC-0073 ), etc.
Informațiile necesare pentru a distribui fișiere prin intermediul conferințelor ecou fișiere sunt conținute într-un fișier însoțitor cu extensia tic . Distribuirea fișierelor în acest mod este descrisă în FSC-0087 . În zilele noastre, când există multe modalități mai avansate de distribuire a fișierelor, ecoconferințele de fișiere din Fido servesc în primul rând la diseminarea informațiilor oficiale.
Se pot distinge următoarele funcții, pentru care sunt destinate programele corespunzătoare:
De fapt, funcțiile unui program sunt adesea îndeplinite de altul. De exemplu, urmărirea netmail poate fi gestionată de către tosser-ul HPT din kitul Husky , iar mailer -ul T-Mail este, de asemenea, capabil să proceseze cererile de fișiere pe cont propriu. În prezent, majoritatea sistemelor sunt doar mailer și tosser.
De fapt, sistemul FTN se limitează la primirea, procesarea și transmiterea mesajelor și fișierelor - bazele de mesaje nu fac parte din sistem. Dacă un fel de conferință ecou nu este stocată în baza de date locală, atunci se numește pass-through (din engleză passthrough ).
Puteți vorbi despre BBS dacă baza de mesaje este prevăzută cu acces multi-utilizator prin rețea. Utilizatorii BBS nu au nevoie de un set complet de programe FTN, ci doar de programul client. BBS-urile bazate pe protocoalele NNTP și HTTP sunt în prezent comune . Utilizatorii nu au propria lor adresă în rețea - scriu de pe adresa sistemului pe care rulează BBS.
FTN în sine nu este legat de canalele fizice de transmisie a datelor, esența sa este offline. Comunicarea are loc după principiul sesiunii: doar două sisteme participă la conexiune, conexiunea este necesară doar pentru o perioadă scurtă de timp pentru a primi și transmite mesaje noi. Informațiile sunt distribuite într-o serie de uplink-uri și downlink-uri. Nodurile de distribuție mari primesc statutul de hub . Legăturile persistente sunt protejate de o parolă, dar dacă sistemul acceptă conexiuni de intrare, atunci, conform listei de noduri sau listei de puncte, îi puteți trimite un mesaj sau fișier direct ("direct") printr-o sesiune fără parole.
Lucrarea cu canalul de transmisie a datelor în sistemul FTN este efectuată de expeditor. Inițial, tehnologia a fost creată pentru comunicare folosind un modem prin linii telefonice , dar de la mijlocul anilor 1990, Internetul a fost folosit pentru a face schimb de corespondență între nodurile Fido mari .
Protocoale de transfer de date utilizate în prezent: binkp ( FTS-1026 ), ifcico ( FTS-1024 ) și fido-over-email ( FTS-1025 și altele) pentru comunicarea prin Internet și EMSI ( FSC-0056 ) pentru conexiune prin modem.
Teoretic, o rețea FTN poate folosi orice număr de rețele fizice în același timp - singura întrebare este să creați corespondenții corespunzători. Fidoshnikii, vorbind despre independența față de canalele de comunicare, adaugă uneori: „chiar și cu poștă de porumbei!” Într-adevăr, pachetele pot fi codificate în UUE , tipărite ca text și trimise cu porumbei, iar pe partea de primire pot fi recunoscute, decodificate și transmise celui care aruncă - porumbelul va fi „mailer”, iar UUE, împreună cu imprimantă și scaner , vor fi un tip specific de intrare/ieșire.
„Inbound” și „outbound” sunt directoare cu date de intrare și de ieșire. Funcția proprie a mailer-ului este doar de a accepta în inbound și transfer de la outbound - procesarea este efectuată de alte programe. Atât recepția, cât și transmiterea e-mailului, în majoritatea cazurilor, pot fi efectuate în mod egal atât în sesiunile de intrare, cât și în cele de ieșire.
Dacă intrarea este întotdeauna aceeași (totuși, de obicei, există directoare de intrare diferite pentru sesiunile cu parolă și fără parolă), atunci ieșirea poate fi de diferite tipuri. Cunoscute sunt ArcMail Attach (AMA), Amiga Style Outbound (ASO) și Binkley Style Outbound (BSO).
ArcMail [3] este folosit pentru a transmite ecou mail - pachetele de mail sunt comprimate de arhivator . De obicei, multe pachete cu mesaje sunt plasate într-un singur pachet archmail. Echomail este transmis ca un arhmail (adică sub formă comprimată) indiferent de tipul de ieșire.
Pachetele Netmail sunt de obicei trimise necomprimate. Atât netmail, cât și echomail folosesc același format de pachet (în prezent tipul de pachet 2+, descris în FSC-0048 ). Formatul în care mesajul este scris în pachet este descris în FTS-0001 .
Există o capcană terminologică aici. Faptul este că deseori poți auzi oamenii spunând „netmail neambalat”. În acest caz, ne referim la netmail, nu comprimat într-un archmail. Pentru a fi trimis, orice mesaj trebuie să fie împachetat într-un pachet (un fișier cu extensia pkt ), dar pachetele echomail sunt comprimate și transmise prin arcmail, în timp ce pachetele netmail sunt transmise singure, fără compresie. Este posibil să transferați prin archmail și netmail, dar acest lucru se face foarte rar.
Se vorbește despre netmail necomprimat ("despachetat") în legătură cu ora poștală. Conform chartei rețelei Fido , nodul de rețea trebuie să poată primi un netmail nearhivat în timpul unei sesiuni fără parolă (clauza 2.1.8 ).
După acceptarea anumitor date în inbound, expeditorul poate rula un program de gestionare sau poate crea un fișier flag.
Dacă expeditorul acceptă un arcmail, atunci lansatorul este lansat . Tosser dezarhivează Arkmail și despachetează pachetele cu mesaje. Când un mesaj este primit într-o anumită zonă de ecou ( AREA kludge ), tosser-ul verifică starea de abonare a legăturilor de sistem către această zonă și împachetează mesaje noi pentru fiecare legătură abonată, după care plasează pachetele create în ieșire. Pentru a preveni retrimiterea unui mesaj către sistemele prin care a trecut deja, există kludge SEEN-BY . Link-urile își pot gestiona abonamentul la o conferință echo folosind managerul de abonamente ( robotul Areafix ) trimițând comenzi speciale prin netmail.
Tosser-ul poate salva mesaje într-o bază de date care poate fi accesată local de un sysop folosind un editor de mesaje sau de la distanță de mai mulți utilizatori printr-un BBS . Expeditorul trebuie să scaneze bazele de date pentru mesaje noi și să le împacheteze pentru a le trimite către legăturile de sistem.
Echomail este descris în FTS-0004 .
Dacă expeditorul acceptă un netmail, atunci este lansat un tracker pentru a-l procesa (deși distribuitorul sau mailer-ul însuși poate îndeplini funcțiile unui tracker). Trackerul despachetează pachetul cu mesaje și acționează cu acestea în conformitate cu setările sistemului. În primul rând, tracker-ul trebuie să direcționeze mesajele de tranzit - dacă mesajul nu este adresat sistemului căruia îi aparține trackerul, acesta va fi împachetat pentru a fi trimis la o altă legătură în conformitate cu regulile de rutare. Înainte de a trimite, tracker-ul inserează în mesaje o linie cu Via kludge , care conține adresa sistemului, timpul de procesare și identificatorul programului de urmărire (formatul acestui kludge este descris în FTS-4009 ). Fiecare sistem de tranzit prin care trece mesajul trebuie să-și introducă propria linie cu Via kludge.
În plus, tracker-ul poate verifica prezența expeditorului și destinatarului mesajului în nodelist și pointlist (aceste documente trebuie să fie la zi), să trimită notificări despre primirea și procesarea mesajului (dacă expeditorul a setat atribute adecvate), trimiteți mesaje către roboți (de exemplu, un server de fax sau un manager de abonament).
Dacă mesajul este adresat sistemului care deține tracker-ul și nu este tehnic (de exemplu, adresat unui robot), atunci trebuie salvat în baza de date de mesaje pentru citire ulterioară de către sysop.
Dacă expeditorul primește un fișier cu extensia tic , atunci în timpul funcționării normale a sistemului de trimitere, aceasta înseamnă că un fișier distribuit de fileechoconference a fost trimis înainte de acest fișier. Fișierul tic este trimis după noul fișier și îndeplinește aceleași funcții față de acesta ca și kludge-urile pentru mesaje, iar pentru procesarea acestuia este necesar să rulați un fileechoprocessor .
Schema de funcționare a procesorului ecou de fișiere este similară cu cea a aruncătorului. Funcția fișierului de ecoconferință și formatul fișierului tic sunt descrise în FSC-0087 .
Dacă expeditorul primește un fișier cu extensia req , înseamnă că o cerere de fișier (freak) a fost trimisă către sistem și ar trebui să fie rulat handlerul corespunzător. Freks sunt descriși în FSC-0086 și FTS-0006 .
Atributele mesajului stabilesc urgența trimiterii, solicitările de notificări de primire sau citire și alți parametri. De exemplu, atributul K/s (de la kill/send ) spune că e-mailul ar trebui să fie șters din baza de date după ce a fost trimis. Un mesaj cu atributul Dir trebuie trimis direct destinatarului, nu prin rutare. Cu atributul Pvt , scrisoarea este considerată privată. Atributul Uns este setat pentru mesajele noi și se modifică în Snt după trimitere. Editorul setează atributul Rcv noului mesaj primit, adresat utilizatorului când îl citește. Atributul Loc înseamnă că mesajul a fost creat în sistem și nu a venit din exterior.
Până când mesajul este trimis, atributele sunt stocate în baza de date a mesajelor. Când sunt transmise, atributele devin parte a mesajului împachetat (formatul mesajului împachetat este descris în FTS-0001 ). Când un tosser scrie mesaje într-un director temporar după despachetare, atributele pot fi scrise în FLAGS kludge ( FSC-0053 ) [4] .
Adesea se folosesc programe suplimentare pentru:
Începând cu 2021, pe lângă FidoNet , multe alte rețele FTN continuă să funcționeze și să facă schimb de mesaje între noduri și BBS. Acestea sunt rețele precum: