FTN (från FidoNet Technology Network ) är en offline-nätverksteknik som används i Fido och Levnets .
FTN är en teknik som har sitt ursprung i Fido-nätverket 1984, och utvecklingen av tekniken drevs av behoven hos den snabbt växande Fido. Det är dock felaktigt att identifiera Fido och FTN, eftersom FTN även kan användas för att skapa andra nätverk som kanske inte är relaterade till Fido på något sätt. Sådana nätverk kallas levnets . Kända fall av användning av FTN-teknik av fidoshniks för att organisera industriella, högt specialiserade nätverk.
Det största och mest komplexa FTN-nätet är FidoNet . I den baseras adressering på geopolitisk tillhörighet, och nätverkets liv styrs av en stadga . Vänsterpartiet är oftast mycket enklare organisatoriskt.
Standarderna enligt vilka FTN-mjukvaran utvecklas är de dokument som antagits av FTSC (Fido Network Technical Standards Committee), men skyldigheten att följa vissa dokument i vänsternäten och Fido kan skilja sig åt.
Enheten i FTN-nätverket är det så kallade systemet - en uppsättning program konfigurerade för att utföra funktioner relaterade till vidarebefordran och bearbetning av post och filer. Den som underhåller systemet kallas systemoperatör ( sysop ). Varje system har en adress.
Standard FTN-adresseringsschemat beskrivs i FSP-1028 . Fullt skriven ser adressen ut så här: Zone:Net/Node.Point@Domain , där de fyra första fälten är fyllda med siffrorna för zonen, nätverket, noden respektive punkten, och det femte är bokstavsbeteckningen för FTN-nätet. En sådan komplett post kallas en 5D-post. Korta former (4D, 3D och 2D) är också möjliga - när program kan anta värden för andra fält.
Systemen är nodala och spetsiga. Skillnaden mellan dem ligger vanligtvis bara i den rättsliga ställningen i nätverket (till exempel i Fido-punkter är inte formellt medlemmar i nätverket). Vid första anblicken verkar värdadressen kortare eftersom den inte innehåller ett nummer efter punkten, men i själva verket finns den alltid, den är helt enkelt noll i värdadresser och är vanligtvis utelämnad. I 5D-form skrivs även nodadresser vanligtvis utan punktnummer.
"Domän"-fältet i en FTN-adress (nätverksbokstav) ska inte förväxlas med Internetdomännamn (se FQDN ). Således kommer domännamnet fidonet.org , som är värd för den officiella webbplatsen för Fido-nätverket, inte att vara en giltig domän när den används i en FTN-adress. Istället ska bara fidonet användas .
Det kan finnas mer än ett system på en dator. För det första kan en uppsättning program konfigureras för att arbeta samtidigt under flera adresser. Då talar man om AKA (från även känd som ) utöver huvudsystemets adress (den första som anges i config ). För det andra kan det finnas flera kit konfigurerade för att fungera oberoende. Detta händer till exempel när en nod har en teknisk punktadress för drift av BBS eller robotar .
Nätverket sköts av tjänstemän - samordnare. Koordinatorer ansvarar för att definiera routingscheman och underhålla nodlistan . En nodlist är en lista över nodsystem som ingår i ett FTN-nätverk. En nodlista innehåller den information som krävs för att ett system ska kunna anropa ett annat över ett publikt nätverk. Punktsystem kan också ta emot inkommande anslutningar, information för att kommunicera med dem läggs in i punktlistan .
Nodelistformatet och flaggorna beskrivs i FTS-5000 , FTS-5001 (kärnstandarder) och FSP-1035 ( DNS Distributed Nodelist ). I Fido beskrivs giltiga flaggor också i nodelist-epilogen. Punktlistformatet beskrivs i FTS-5002 .
FTN-nätverk har möjligheter för överföring av textmeddelanden och filer. Textmeddelanden kan delas in i netmail (personlig korrespondens) och echomail (offentliga temakonferenser). Fildelningsverktyg inkluderar filekokonferenser (distribution av filer efter tematiska kategorier) och filförfrågningar (begäran om en specifik fil från ett system från ett annat). Men textmeddelanden för UUE -kodade filer är också vanligt .
Under lång tid satte FTN-nätverk gränser för storleken på ett meddelande (till exempel reglerna för ekokonferenser), på grund av bristerna i de program som användes vid den tiden. Efter hand tilläts större storlekar. sista tänkbara gränsen var 64 KB [1] eftersom proprietära programmet FastEcho fortfarande finns kvar[ när? ] populär nog för att inte kunna hantera fler [2] . Men det pågår en livlig debatt i Fido nu för tiden, och fler och fler människor går bort från den till förmån för modernare program som inte har några begränsningar för meddelandestorlekar.
Befintliga FTN-meddelanderedigerare stöder inte Unicode och uppmärkningsmetoder. Detta resulterar i att endast vanlig, oformaterad text i CP866 eller annan enkelbytekodad teckenuppsättning sänds över FTN . FTN låter dig skicka meddelanden i valfri kodning som innehåller eventuella uppmärkningstaggar, men det finns inga redigerare som stöder dem.
För att ställa in olika egenskaper hos det överförda meddelandet infogas speciella kontrollrader i it -kludges , liknande RFC-huvudet för e-postmeddelanden . En allmän beskrivning av kludgesna finns i FTS-4000 , men själva kludgesna beskrivs i separata dokument. Varje meddelande måste innehålla MSGID kludge ( FTS-0009 ), meddelandekodningen anges i CHRS kludge ( FTS-5003 ), krypterade eller EDS -signerade meddelanden indikeras av ENC kludge ( FSC-0073 ), etc.
Den information som behövs för att distribuera filer via file echo-konferenser finns i en medföljande fil med en tic -tillägg . Att distribuera filer på detta sätt beskrivs i FSC-0087 . Nuförtiden, när det finns många mer avancerade sätt att distribuera filer, tjänar filekokonferenser i Fido främst till att sprida officiell information.
Följande funktioner kan urskiljas, för vilka motsvarande program är avsedda:
Faktum är att funktionerna i ett program ofta utförs av ett annat. Netmail-spårning kan till exempel hanteras av HPT-tossern från Husky -kitet, och T-Mail- mailern kan också behandla filförfrågningar på egen hand. För närvarande är de flesta system bara mailer och tosser.
Faktum är att FTN-systemet är begränsat till att ta emot, bearbeta och sända meddelanden och filer - meddelandebaser är inte en del av systemet. Om någon form av ekokonferens inte finns lagrad i den lokala databasen, så kallas det pass-through (från engelska passthrough ).
Du kan prata om BBS om meddelandebasen är försedd med åtkomst för flera användare över nätverket. BBS-användare behöver inte en fullständig uppsättning FTN-program, utan bara klientprogrammet. BBS baserade på NNTP - och HTTP - protokollen är för närvarande vanliga . Användare har ingen egen adress i nätverket - de skriver från adressen till systemet som BBS körs på.
FTN i sig är inte bunden till fysiska dataöverföringskanaler, dess kärna är offline. Kommunikation sker enligt sessionsprincipen: endast två system deltar i anslutningen, anslutningen krävs endast under en kort tid för att ta emot och sända nya meddelanden. Informationen distribueras i en serie upplänkar och nedlänkar. Stora distribuerande noder får status som ett nav . Beständiga länkar skyddas av ett lösenord, men om systemet accepterar inkommande anslutningar kan du enligt nodlistan eller punktlistan skicka ett meddelande eller en fil till den direkt ("direkt") genom en session utan lösenord.
Arbetet med dataöverföringskanalen i FTN-systemet utförs av utsändaren. Till en början skapades tekniken för kommunikation med ett modem över telefonlinjer , men sedan mitten av 1990-talet har Internet använts för att utbyta post mellan stora Fido-noder .
För närvarande använda dataöverföringsprotokoll: binkp ( FTS-1026 ), ifcico ( FTS-1024 ) och fido-over-e-post ( FTS-1025 och andra) för Internetkommunikation och EMSI ( FSC-0056 ) för modemanslutning.
Teoretiskt sett kan ett FTN-nät använda hur många fysiska nätverk som helst samtidigt - den enda frågan är att skapa lämpliga utskick. Fidoshniks, på tal om oberoende från kommunikationskanaler, lägger ibland till: "även med duvpost!" Faktum är att buntar kan kodas i UUE , skrivas ut som text och skickas med duvor, och på mottagningssidan kan de kännas igen, avkodas och överföras till tossaren - duvan kommer att vara "mailer" och UUE, tillsammans med skrivare och skanner , kommer att vara en specifik inkommande/utgående typ.
"Inkommande" och "utgående" är kataloger med inkommande och utgående data. Avsändarens egen funktion är endast att ta emot till inkommande och överföra från utgående - bearbetning utförs av andra program. Både mottagning och överföring av försändelsen kan i de flesta fall utföras lika på både inkommande och utgående sessioner.
Om den inkommande alltid är densamma (men vanligtvis finns det olika inkommande kataloger för lösenords- och icke-lösenordssessioner), så kan den utgående vara av olika typer. Kända är ArcMail Attach (AMA), Amiga Style Outbound (ASO) och Binkley Style Outbound (BSO).
ArcMail [3] används för att sända eko- postpaket som komprimeras av arkivet . Vanligtvis är många paket med meddelanden placerade i ett arkmailpaket. Echomail sänds som en archmail (det vill säga i komprimerad form) oavsett utgående typ.
Netmail-paket skickas vanligtvis okomprimerade. Både netmail och echomail använder samma paketformat (för närvarande pakettyp 2+, beskrivet i FSC-0048 ). Formatet i vilket meddelandet skrivs till paketet beskrivs i FTS-0001 .
Det finns en terminologisk fälla här. Faktum är att du ofta kan höra folk säga "unpackaged netmail". I det här fallet menar vi netmail, inte komprimerad till en archmail. För att skickas måste alla meddelanden packas i ett paket (en fil med tillägget pkt ), men echomail-paket komprimeras och sänds med arcmail, medan netmail-paket sänds av sig själva, utan komprimering. Det är möjligt att överföra med archmail och netmail, men detta görs mycket sällan.
Okomprimerad ("uppackad") netmail talas om i samband med posttimmen. Enligt stadgan för Fido-nätverket måste nätverksnoden kunna ta emot en oarkiverad netmail under en session utan lösenord (klausul 2.1.8 ).
Vid acceptans av viss data till den inkommande, kan avsändaren köra ett hanterarprogram eller skapa en flaggfil.
Om avsändaren accepterar en arcmail, så startas tossern . Tosser packar upp Arkmail och packar upp paketen med meddelanden. När ett meddelande tas emot i ett visst ekoområde ( AREA kludge ), kontrollerar tossaren prenumerationsstatusen för systemlänkarna till detta område och packar nya meddelanden för varje prenumererad länk, varefter den placerar de skapade buntarna i den utgående. För att förhindra att ett meddelande skickas igen till system som det redan har passerat genom, finns det SEEN-BY kludge . Länkar kan hantera sin prenumeration på en ekokonferens med hjälp av prenumerationshanteraren ( Areafix- roboten ) genom att skicka speciella kommandon via netmail.
Tossaren kan spara meddelanden till en databas som kan nås lokalt av en sysop med hjälp av en meddelanderedigerare eller på distans av flera användare via en BBS . Tossaren måste skanna databaser efter nya meddelanden och paketera dem för att skicka till systemlänkar.
Echomail beskrivs i FTS-0004 .
Om avsändaren accepterar en netmail, startas en spårare för att bearbeta den (även om sändaren eller avsändaren själv kan utföra funktionerna som en spårare). Spåraren packar upp paketet med meddelanden och agerar med dem i enlighet med systeminställningarna. Först och främst måste spåraren dirigera transitmeddelanden - om meddelandet inte är adresserat till systemet som spåraren tillhör, paketeras det för att skickas till en annan länk i enlighet med dirigeringsreglerna. Före sändning infogar spåraren en rad med Via kludge i meddelandena , som innehåller adressen till systemet, bearbetningstiden och spårningsprogrammets identifierare (formatet för denna kludge beskrivs i FTS-4009 ). Varje transiteringssystem genom vilket meddelandet passerar måste infoga sin egen linje med Via kludge.
Dessutom kan spåraren kontrollera närvaron av avsändaren och mottagaren av meddelandet i nodlistan och punktlistan (dessa dokument måste vara uppdaterade), skicka meddelanden om mottagande och bearbetning av meddelandet (om avsändaren har ställt in lämpliga attribut), skicka meddelanden till robotar (till exempel en faxserver eller en prenumerationshanterare).
Om meddelandet är adresserat till systemet som äger spåraren och inte är tekniskt (till exempel adresserat till en robot), måste det sparas i meddelandedatabasen för senare läsning av sysop.
Om avsändaren tar emot en fil med filtillägget tic , betyder det under normal drift av det sändande systemet att en fil som distribuerats av fileechoconference skickades före denna fil. Tic-filen skickas efter den nya filen och utför samma funktioner med avseende på den som kludges för meddelanden, och för dess bearbetning är det nödvändigt att köra en fileechoprocessor .
Operationsschemat för filen ekoprocessor liknar det för tossern. Funktionen för ekokonferensfilen och formatet för tic-filen beskrivs i FSC-0087 .
Om avsändaren tar emot en fil med ett req -tillägg betyder det att en filbegäran (freak) har skickats till systemet och lämplig hanterare bör köras. Freks beskrivs i FSC-0086 och FTS-0006 .
Meddelandeattributen anger hur brådskande sändningen är, förfrågningar om aviseringar om mottagande eller läsning och andra parametrar. Till exempel säger attributet K/s (från kill/send ) att mejlet ska raderas från databasen efter att det har skickats. Ett meddelande med Dir- attributet måste skickas direkt till mottagaren, inte via routing. Med Pvt- attributet anses brevet vara privat. Uns- attributet ställs in på nya meddelanden och ändras till Snt efter sändning. Redaktören ställer in Rcv- attributet till det nya mottagna meddelandet, adresserat till användaren när han läser det. Attributet Loc betyder att meddelandet skapades i systemet och inte kom utifrån.
Tills meddelandet skickas lagras attributen i meddelandedatabasen. När de överförs blir attributen en del av det paketerade meddelandet (formatet för det paketerade meddelandet beskrivs i FTS-0001 ). När en tosser skriver meddelanden till en temporär katalog efter uppackning, kan attribut skrivas i FLAGS kludge ( FSC-0053 ) [4] .
Ofta används ytterligare program för:
Från och med 2021, förutom FidoNet , fortsätter många andra FTN-nätverk att fungera och utbyta meddelanden mellan noder och BBS. Dessa är nätverk som: