NO174910B - Inngangs-/utgangsnettverk for datamaskin - Google Patents

Description

Denne oppfinnelsen angår forbedring av inngang/utgangsdelen i en datamaskin, og er spesielt nyttig for en kostnadseffektiv tilknytning til datamaskinen av et forholdsvis stort antall inn/ut-innretninger eller periferenheter av lav til middels hastighet spredt over et relativt stort geografisk område for å oppnå effektiv tidsdeling av datamaskinsystemets ressurser og effektiv kommunikasjon mellom inn/ut-innretningene og datameskinsystemet.

Bakgrunn for oppfinnelsen.

Det økende kravet til tidsdeling av datamaskinressurser blant en mengde forskjellige eksterne inn/ut-innretninger av forholdsvis lav hastighet har medført mange endringer i datamaskinarkitekturen gjennom årene. En god del av disse endringene har dreid seg om inn/ut-subsystemet. Inn/ut-kontrollere er konstruert for å unngå å begrense den tilgjengelige hastighet på dagens prossesorenheter og tilstrebe å betjene et økende antall inn/ut-enheter. Inn/ut-kontrollere er vanligvis enten av masselager eller karaktertype. En inn/ut-kontroller for masselager brukes for å styre høyhastighets-overføring av relativt store datamengder fra en eller flere eksterne masselagre som f.eks. platelagre, via datamaskinens buss til systemets primærlager. Da antall over-føringer til og fra masselageret er forholdsvis lite og datamengden ved hver enkelt kontinuerlig høyhastighetsoverføring er forholdsvis stor, er effektiviteten ved masselager kanal-kontrolleres operasjon vanligvis ikke betraktet som noen vesentlig begrensning. En har imidlertid fått betydlige begrensninger ved å forsøke å overføre mindre datamengder, vanligvis karakterer, forholdsvis ofte etter hverandre, som er tilfallet ved forholdsvis mange av lav- til middelhastighets inn/ut-innretninger som f.eks. terminaler og skrivere. Karakter inn/ut-innretningen som har blitt utviklet som svar på den økende bruken av lav til middels hastighets inn/ut-innretninger har blitt mer og mer kompleks, og vil snart gi minkende effektivitet i forhold til de forbedringer som måtte oppnås.

Den mest vanlige utgaven av inn/ut-kanal-kontrollere nytter sin egen, forholdsvis komplekse prosessor for å multiplekse data til og fra et bestemt antall (8,16 eller 32) tilkoplede inn/ut-innretninger. Karakter-kanal-kontrollerens inn/ut-porter kan være begrenset til en bestemt type enhet for dedikert lokal tilkopling. Hvis karakter-kanal-kontrolleren ikke er enhetsdedikert, kreves det et tilsvarende komplekst inn/ut-adapter mellom inn/ut-kanalen og hver enhet, eventuelt hver gruppe av enheter. De operasjonelle funksjonene hos inn/ut-innretnings-kontrolleren, inn/ut-adapteret, vertsdatamaskinen og inn/ut-innretningene er delt mellom alle disse komponentene. Kommunikasjonen og protokollen for å oppnå slik kommunikasjon er vanligvis kompleks, krever betydelige overflødighet i operativsystemet, kompliserer vanligvis overføringen av inn/ut-data og begrenser oftest behandlingsevnen.

De fleste kostnader i forbindelse med å kople enheter til datamaskinen kommer som en følge av av den forholdsvis komplekse operasjonsmåten hos inn/ut-proses-sorene i kanal-kontrolleren og adapterne og protokollen som kreves. For å minske endel av disse relativt høye kostnadene, er det vanlig å lage mange porter på hvert inn/ut-adapter i den hensikt å tilkople mange inn/ut-innretninger. Inn/ut-innretningene må vanligvis lokaliseres fysisk nært inn/ut-adapteret da kabellengeden kan begrense den hastigheten som pålitelig dataoverføring kan foregå ved. For å tilkople en ny inn/ut-innretning til en datamaskin i det tilfellet det ikke fins en ubrukt port på et multiports inn/ut-adapter, må et nytt multiports inn/ut-adapter tilkoples kanal-kontrolleren. Brukerens tilkoplingskostnader er ikke nødvendigvis relatert til hver ny tilkopling av inn/ut-innretning til systemet, da tilkoplingen av hver ny multiports adapter medfører å måtte betale for muligheten å tilkople en mengde inn/ut-innretninger enten disse brukes eller ikke. I enkelte situasjiner kan tilkoplingskostnadene overstige kostnadene ved selve inn/ut-innretningen.

Metoden for multipleksing som nyttes i karakter inn/ut-kanal-kontrollere og

-adaptere kan også skape begerensninger. En type mulitpleksing er kjent som sentral spørring. Ved sentral spørring sender den sentrale prosessoren forespørsler til hver inn/ut-innretning i tur og orden og uavhengig om den har noe data å sende eller ikke. En annen form for spørring, kjent som indusert spørring eller spørring etter ønske, setter igang denne typen sentral spørring bare når et adapter sender et status-endret signal. Med indusert spørring unngår en den arbeidsbyrde som kontinuerlig spørring av alle adaptrene og inn/ut-innretningene er for prosessoren, men krever at alle adaptrene blir spurt en gang i rekkefølge ved enhever spørresekvens. Spørring krever betydlig programmessig funksjonalitet enten hos prosessorenheten eller kanal-

kontrolleren, og sløser med tid ved at både de aktive og de passive inn/ut-innretningene spørres, og ved tolking av resultatet av spørringen.

En annen type multipleksing er generelt referert til som tilgang på forespørsel. Tilgang på forespørsel innebærer som regel et tilgangsønske fra et adapter til kommunikasjons-leddet, og en form for utvelging for å skille mellom tilgangsønske fra de forskjellige adaptre. Signalforsinkelsen i utvelgingssystemet kan skape betydlige uhel-dige påvirkninger. Da signalforsinkelsen øker med økende kabellengde er utvelg-elsesteknikker som benytter prosessor-enheten eller systembuss-kontrolleren for å sortere tilgangsønsker, kjent som sentrale utvelgelsessystemer, vanligvis begrenset til datameskinebussen og andre applikasjoner der avstanden mellom inn/ut-adaptrene som genererer ønskene og utvelgelseslogikken er maksimalt en meter.

Tegnsending etter stafettpinneprinsippet er en teknikk for distribuert kontroll eller utvelgelse som med hell har vært benyttet i lokale nettverk.

US-4495493 beskriver et konvensjonelt nettverk, og angår medietilgang styring for nodene ved det lokale nettverket. Det er ikke er relevant med hensyn på kommunikasjon på sesjonsnivå: ""The upper levels, for example session, presentation, applica-tion (terminology OSI) cooperate with the lower levels but they will not be described herein because they are essentially formed by logic and are known". (kolonne 7, linjene 64-69). I samsvar med dette er det i US-4495493 ikke vist eller foreslått en separat IONET kommunikasjonsprotokoll som opererer ved nivå over det lokale nettverkets kommunikasjonsprotokoll for å etablere kommunikasjon på sesjonsnivå mellom sesjonspartner-innretninger uten innblanding fra andre IONET-beskjeder gjennom sesjonen. Heller ikke er vist inkludering av IONET-beskjeder i datafeltene ved lokale nettverk datapakker, overføring av styringsfunksjonsinformasjon og bytestrømdata i enkle IONET-beskjeder for samtidig å utføre styringsfunksjoner, mens bytestrømdata overføres umodifisert til innretningene, eller bruk av bruks-punktorganer ved hver node for å implementere separat IONET kommunikasjonsprotokoll.

Ved US-44574284 er det nødvendig med separate kommunikasjonsmodi, såsom en for data og en annen for styringsfunksjoner. Videre trengs et separat medium eller kabelsett for å kommunisere styringsfunksjoner.

I US-4574284 er det vist at bussinterface-enhetene er omskiftbar mellom en separat kommandomodus der informasjonen fra brukerinnretningen ikke oversendes til bussen og en tilkoplet modus der informasjonen fra brukerinnretningen sendes til bussen. Med bussen ser det ut til at to separate og ikke-samtidige kommunikasjonsmodi er gjennomført; en for å overføre bytestrømdata, og en annen for å overføre styringsfunksjonskommandoer. Det er imidlertid ikke inkludert fordelen ved samtidig kommunikasjon av styringsfunksjonal administrativ informasjon sammen med byte-strømdata, uten å avslutte sesjonen. Videre anvender US-4574284 reserverte eller spesielle koder (f.eks. carriage return) i bytestrømdata kommunisert til å oppnå visse styringsfunksjoner, og oppnår dermed ikke transparent bytestrømdataoverføring.

US-4423414 er relevant på et lokalt nettverksnivå når det gjelder en "lokal kommando".

Kort sammendrag av oppfinnelsen.

Den foreliggende oppfinnelsen er konstruert som inn/ut-nettverk (IONET) -kanal for et datamaskinsystem. Generelt er IONET beregnet for høyeffektiv karakter- og

annen kommunikasjon mellom flere lav- til middelshastighets enheter av samme eller forskjellig type, koplet direkte til inn/ut-subsystemet hos en datamaskin, ved hjelp av utvelgelse over et kommunikasjonsmedium av type lokalt nettverk, forholdsvis rimelige adaptre med mikrodatamaskiner distribuert over mediet og koplet til hver inn/ut-innretning eller et mindre antall inn/ut-innretninger, og en kommunikasjon- og styringsprotokoll som effektivt styrer mikrodatamaskinene og for å styre datakommunikasjonen mellom inn/ut-innretningene og datamaskinsystemets hukommelse. Kommunikasjonsmediet av type lokalt nettverk, protokollen og det distribuerte lav-kostsadaptret danner sammen en forbedret inn/ut-kanal-kontroller, men uten de begrensningeer som tidligere er anført.

Inn/ut-innretningene kan tilkoples i betydelig lengre avstander fra sentralenheten, fordi utvelgelsesmekanismen tillater slike tilkoplinger uten å redusere dataover-føringsevnen, og fordi lokalt nettverk gir pålitelig kommunikasjon over lengre avstander enn andre løsninger som nytter lavkosts kabling. Kommunikasjon- og styringsprotokollen er forholdsvis enkel, krever ikke betydlig merarbeid, og gir effektiv dataoverføring. De distribuerte adaptrene er forholdsvis enkle å implementere og responderer direkte og effektivt til protokollens kommandoer om dataoverføringer. Brukeren pådrar seg forholdsvis lave kostnader, faste pr. tilkopling, ved hver ny tilkopling av inn/ut-innretninger til systemet, og unngår dermed den høye kostnaden forbundet med dyre enkelt-adaptre for delingslogikk samt restrik-sjonene for fysisk plassering ved tilkopling av inn/ut-innretningen til disse adaptrene. Inn/ut-innretningene kan lokaliseres på vidt forskjellige steder. Dataoverføringen krever ikke tidsdeling av den langt raskere sentralenheten, på tross av at kommunikasjonen foregår med inn/ut-innretninger av betydelig lavere hastighet. Brukere av hver inn/ut-innretning har tilgang til alle systemets ressurser uten å plassere et komplett datamaskinsystem ved hver inn/ut-innretning eller terminal.

Foreliggende oppfinnelses protokoll gir en betydelig bevaring av nettverkets båndbredde, fordi den innlemmer flytkontroll på transportnivå. Datapakker vil ikke bli sendt før det er klart at pakkene kan bli mottatt. Protokollen er generelt immun mot tap eller duplisering av enhver pakke til enhver tid. Hvis en pakke er duplisert eller tapt, vil systemet av natur bli gjenopprettet på transportnivå. Databeskjeder kan bli videresendt mellom separate nettverks-segmenter. Oppfinnelsen kan også tillate en privat tilkoplet logisk enhet selv i et multiprosessorsystem, noe som er svært nyttig av sikkerhetsmessige årsaker, og avgrenser tilgangen til informasjonen. En betydelig del av multiplekserfunksjonen og nettverkskontrollenfunksjonen er flyttet inn i protokollen.

Den foreliggende oppfinnelsen kan bedre forstås på bakgrunn av den følgende detaljerte beskrivelsen av en foretrukket implementering av oppfinnelsen, som også er illustrert i de medfølgende tegninger som er summarisk beskrevet nedenfor. Det egentlige formålet med oppfinnelsen er definert i de vedlagte krav, og beskrivelsen av oppfinnelsen overfor skal bare betraktes som et generelt sammendrag av spesielle trekk.

Kort beskrivelse av tegningene.

Figur 1 er et generelt blokkdiagram av et typisk datamaskinsystem av eldre teknologi, der en masselager inn/ut-kanal, en karakter inn/ut-kanal og et lokalt nettverk er tilkoplet. Figur 2 er et generelt blokkdiagram av et datamaskinsystem som bruker IONET-kanalen i foreliggende oppfinnelse. Figur 3 er et blokkdiagram som illustrerer sammenkoplingen av flere inn/ut-kanaler ved hjelp av flere IONET-kanaler til et enkelt datamaskinsystem. Figur 4 er et blokkdiagram som illustrerer sammenkoplingen av flere datamaskinsystemer til flere inn/ut-innretninger ved hjelp av en IONET-kanal. Figur 5 er et blokkdiagram som illustrerer sammenkoplingen av flere datamaskinsystemer innbyrdes koplet til et lokalt nettverk, og hvert datamaskinsystem har en IONET-kanal som kopler flere inn/ut-innretninger til hvert datamaskinsystem. Figur 6 er et blokkdiagram over et distribuert adapter for IONET-kanalen som forbinder en inn/ut-innretning til IONET-kanalens kabel. Figur 8 er et blokkdiagram av et eksempel på distribuert adapter som nytter RS 232 serielt grensesnitt. Figur 9 er en illustrasjon av den sju-lags Open System Interface (OSI) arkitekturen som er International Standards Organization sin referansemodell for kommunikasjon. Figur 10 er en illustrasjon av en IONET-pakke med informasjon som sendes over IONET-kanalen, vist i form av sekvensielle bytes (bitgrupper). Figur 11 er en illustrasjon av den IONET-pakken som vist i figur 10, brutt ned i de hierarkiske nivå som tilsvarer fysisk-, lenke-, nett-, transport- og sesjonsnivå i OSI-modellen. Figur 12 er et diagram som illustrerer i større detalj det bit-vise utlegget og andre detaljer i noen av de individuelle bytes hos IONET-pakkene vist i figur 10. Figur 13 er en illustrasjon av et generelt tilstandsendirngsdiagram for en sendertilstandmaskin for det distribuerte adaptret for foreliggende oppfinnelse. Figur 14 er en illustrasjon av et generelt tilstandsendringsdiagram for en mottakertilstandmaskin for det distribuerte adaptret for foreliggende oppfinnelse. Figur 15 er et diagram som viser funksjonen av sendertilstandsmaskinen i normal modus. Figur 16 er et diagram som viser funksjonen av sendertilstandsmaskinen i øyeblikkelig modus. Figur 17 er et diagram som viser funksjonen av mottakertilstandsmaskinen i normal modus. Figur 18 er et diagram som viser funksjonen av mottakertilstandsmaskinen i øyeblikkelig modus.

Detaljert beskrivelse.

Den foreliggende oppfinnelsen kan bedre forstås med referanse til et datamaskin-system 100 av eldre teknologi, som er illustrert i figur 1. Datamaskinsystemet 100 omfatter den typiske prosessoren 102, som er tilkoplet og kan kommunisere med den typiske primærhukommelsen 104. Et typisk inn/ut-subsystem 106 er tilgjengelig for kommunikasjon til og fra primærhukommelsen 104. Prosessoren 102, primærhukommelsen 104 og inn/ut-subsystemet 106 er alle i stand til å kommunisere med hverandre med den høye interne kapasitet eller båndbredde som kjennetegner et moderne datamaskinsystem. Inn/ut-subsystemet 106 vil ha en eller flere tilkoplingsmuligheter for eksterne periferenheter. Disse eksterne tilkoplinger er typisk kalt inn/ut-kanaler. I de fleste moderne datamaskiner er to typer inn/ut-kanaler tilgjengelige. En type inn/ut-kanel er masselager inn/ut-kanal 108. Masselager inn/ut-kanalen 108 er karakterisert ved å tilby de overføringene med høy båndbredde som er typisk for lagringsmediene platelager 110 og båndstasjon 112. En masselager inn/ut-kanel 108 er typisk begrenset til et par meter i lengde. En masselager kanal 108 er i stand til å foreta dataoverføringer til og fra bare en inn/ut-innretning i gangen, selv om noen masselager kanaler er i stand til å takle overlappende operasjoner der forskjellige enheter aksesserer data samtidig, men bare én fysisk overfører data til enhver tid. Generelt er ikke en masselager-kanal optimalisert for å ta seg av lavhastighets eller mindre sammenhengende dataoverføringer mellom systemets hukommelse og inn/ut-peirferenheter på grunn av bl.a. forholdsvis høye kablingskostnader, forholdsvis innviklete grensesnittskretser, restriksjoner i fysiske avstander, samt optimal-iseringen av masselager-kanalen 108 for overføring av relativt stor blokker av data ved hver overføring.

For å gi mulighet til et forholdsvis stort antall individuelle overføringer av forholdsvis lite omfang av data, har de flests datamaskinsystemer innebygd en karakter inn/ut-kanal 114. Uttrykket "karakter" beskriver den mest vanlige bruken, å over-føre data enheter som representerer alfanumeriske- og spesialkarakterer til og fra eksterne periferenheter. Uttrykket "karakter" innebærer likevel ikke den restriksjon at bare karakterer kan overføres. Grafiske data, vilkårlige binære data og andre informasjonskodinger kan overføres over karakter inn/ut-kanalen 114. Karakter inn/ut-kanalen 114 er kjennetegnet ved at parallell eller seriell databit overføring foregår ved hastigheter som generelt er lavere enn den hos masselager-kanalen 108, men med en hastighet som er større enn noen av de individuelle periferenhetene som er tilkoplet til karakter inn/ut kanalen 114. Karakter inn/ut-kanalen 114 er optimalisert for korte overføringer til et forholdsvis stort antall periferenheter heller enn lange overføringer til et forholdsvis lite antall enheter.

I små til middels datamaskinsystemer, er den mest vanlige måten å kople til periferenheter på, å nytte en eller flere multiport grensesnitt, eller adapter 116 koplet til kanalen 114. Typisk vil adapteret 116 være en del av hele datamaskinsystem 100. Et antall lavhastighets, parallell eller seriell kommunikasjonsgrensesnitt 118 går ut fra datamaskinsystem 100 og er elektrisk koplet til, og kommuniserer med periferenheter som f.eks. terminal 120, printer 122 og modem 124. Grensesnittet 118 er typisk lavhastighets kommunikasjonskabler som kan være av begrenset lengde hvis ikke modem er brukt, er begrenset i hastighet normalt til maksimalt noen titusen kilobit pr. sekund, og begrenser systemets kapasitet, fordi hver enkelt av kablene 118 tar betydelig plass på bakpanelet av datamaskinen. Ofte er antall eksterne kabler 118 som et datamaskinsystem kan tilby, mer begrenset av plassen på bakpanelet heller enn den egentlige tilgjengelige båndbredden hos datamaskinsystemet.

Typisk er det også vanlig å kople flerports adapteret direkte til inn/ut-karakterkanalen 114, i eller i umiddelbar nærhet av datamaskinens kasse. Slik direkte tilkopling er imidlertid begrenset til en forholdsvis kort avstand, derfor må flerports adapteret 116 plasseres i en avstand som ikke er vesentlig langt unna selve datamaskinen.

I de fleste større datamaskiner inkluderer flerports adapteret 116 en egen prosessor, ofte benevnt frontprosessor, som kontrollerer kommunikasjonen og multi-pleksingen mellom de forskjellige periferenhetene og datamaskinsystemet 100. Funksjonaliteten til adapteret 116 tenderer til å være temmelig kompleks, og krever derfor en forholdsvis kompleks og kostbar prosessor for seg selv for å forhindre at prosesseringsbehovet for å kontrollere de lavhastighets inn/ut enheter fra å belaste kontrollprosessoren 102 for hardt. Vidre tenderer kommunikasjonen og protokollen mellom inn/ut-subsystemet 106 og flerports adapteret 116 å bli kompleks og kreve betydelig intern kommunikasjonsadministrasjon til og fra system hukommelsen 104, for å gi multipleksing mellom periferenhetene.

Kostnaden ved delt logikk og den forholdsvis komplekse maskinvaren som kreves i hvert av de flerports adaptrene 116, har krevd at de har mulighet til å kople til mange periferenheter, typisk minst 4, vanligvis 8 eller 16, og noen ganger 32 periferenheter. En har dermed oppnådd kostnadseffektivitet, forutsatt at det virkelig er et stort antall periferenheter som skal koples til hvert adapter 116. Hvis alle grensesnitt eller kabler 118 være opptatt, er det nødvendig for brukeren å kople ennå et flerports adapter 116 til datamaskinsystemet for å gi plass til neste periferenhet. Den inkrementelle kostnaden for å tilkople en periferenhet i tillegg kan bli ekstremt høy eller prohibitiv, og kan godt overstige kostnaden ved selve periferenheten. Videre, på grunn av avstandsbegrensningene hos karakter inn/ut-kanalen 114 og begrensningene i lengde hos grensesnittkabel 118, må alle periferenhetene fysisk lokaliseres relativt nært opp til flerports adapteret 116.

Innretninger som stort sett har de samme egenskaper som flerports adapteret 116 beskrevet overfor, er noen ganger benevnt inn/ut-kanal kontrollere.

I mange tilfeller er et lokalt nettverk ("Local Area Network", "LAN"), benevnt 126, også koplet til datamaskinsystemet 100. Typisk er et "LAN"-adapter 125 brukt mellom "LAN"-mediet 128 og inn/ut-subsystemet 106. Dette "LAN"-adapteret er det mest vanlig å kople til karakter inn/ut-kanalen 114. Et "LAN" inkluderer typisk et nettverkskommunikasjonsmedium eller kabel 128 som mange datamaskiner er koplet til i den hensikt å dele informasjon. Hver av datamaskinene er koplet til "LAN"-kabelen 128 ved et tappepunkt 130. Hvert system som er tilkoplet "LAN"-kabelen 128 ved et tappepunkt 130 er benevnt en node. Forskjellige varianter av lokale nettverk fins, så som tegnringer, tegnbusser, konfliktsdelte busser, osv. Den mest signifikante forskjellen mellom de ymse konvensjonelle lokale nettverk er basert på hvor sofistikert programvaren er, og derfor kan tilby forskjellige grader av ressursdeling og funksjonalitet.

Nettverkskabelen 128 kan strekkes relativt lange avstander fra verts- eller hoved-datamaskinen 100 til de øvrige nodene. Noen av disse nodene er andre generelle datamaskinsystemer 100. Noen noder i det lokale nettverk kan være spesial enheter kjent som frontprosessorer 132. Frontprosessorer er noen ganger kalt klasekont-rollere. Frontprosessorene 132 gir ikke generelle databehandlingsmuligheter, men fungerer som et transparent grensesnittselement som tillater tilkopling av terminaler 134 eller andre inn/ut-tilkoplinger som ikke er datamaskiner. Selv om klasekontrollerne er koplet til inn/ut-subsystemet 106 over nettverket 126 gjennom et "LAN"-adapter 125, vil ulempene diskutert i sammenheng med flerports adapteret 116, som kommer av den komplekse prosesseringen, tungvindt administrasjon, og delt logikk for multipleksing, også gjelde for hver av de omtalte klasekontrollerne. Ganske visst er er kostnadseffektiviteten hos hver klasekontroller 132 avhengig av å tilkople et forholdsvis stort antall inn/ut-innretninger 134 over relativt korte avstander. Den inkrementelle kostnaden ved å kople flere terminaler til det lokale nettverket er vanligvis forstørret, da ikke alle terminaler kan lokaliseres fysisk nær klasekontrolleren. Som en konsekvens av dette, må det tilkoples flere klase-kontrollere eller andre frontprosessorer enn absolutt nødvendig bare for å tilpasse den fysiske plasseringen av inn/ut-innretningene. Dette forhold bidrar betydelig til kostnaden ved tilkopling av flere inn/ut-innretninger.

I motsetning til et datamaskinsystem av eldre teknologi, er den foreliggende oppfinnelsen presentert generelt i figur 2. Et inn/ut nettverk (IONET) kanal 140 er tilgjengelig for å kople datamaskinsystemet 100 til mange inn/ut-innretninger, f.eks. terminaler 142, skrivere 144, personlige datamaskiner 146, forskjellig datainn-samlings-utstyr 148, modem 150, og statiske multipleksere 152. Modemet 150 kommuniserer over telefonlinje 154 med f.eks. et fjernt datamaskinsystem 156. Den statiske multiplekseren 152 kommuniserer over telefonlinjen 158 til en tilsvarende fjern enhet 160. Mange fjerne terminaler 162 er koplet til den fjerne statiske multiplekseren 160. De statiske multiplekserne 152 og 160 reduserer telefonkostnaden ved å kombinere de aggregerte inn/ut-transaksj onene som går til og fra de mange sam-lokaliserte, fjerne terminalene 162 på en felles telefonlinje 158. Det som her er benevnt med "inn/ut-innretning" er en periferenhet som ikke er i stand til å operere på egen hånd og krever en eller annen form for grensesnitt for å koples til en datamaskin, og skal skilles fra "innretning" som har sin egen prosessor som beskrevet med større detaljering nedenfor. En inn/ut-innretning foretar overføring av inn/ut-informasjon.

IONET-kanalen 140 kombinerer spesielle egenskaper hos et lokalt nettverk av tegnsendingsprinsippet, og karakter inn/ut-kanal for å oppnå betydelige forbedringer ved tilkopling av et forholdsvis stort antall lav til middels hastighets inn/ut-innretninger til datamaskinsystemet samtidig som en unngår mange av de betydelige begrensningene som fins i dagens systemer. Selv om IONET-kanalen 140 primært er en karakterkanal, kan forskjellige datastrømmer dirigeres over denne kanalen, og bruken er ikke begrenset til bare karakteroverføringer.

IONET-kanalen 140 omfatter en kommunikasjonskabel 170, flere distribuerte adaptere 172 koplet til kabelen 170, og midler for å kople til datamaskinsystemet 100 er ved node 174. Uttrykket "node" refererer seg til den elektriske tilkoplingen til kabelen, og må ikke forveksles med uttrykket "node" som generelt refererer seg til alt elektrisk utstyr som koples til en node, som er beskrevet mer i detalj nedenfor. IONET-kanalen 140 kan bli midlet for grensesnitt som kopler datamaskinsystemet 100 til de forskjellige inn/ut-innretningene. En inn/ut-innretning er ment å omfatte alle varianter av forskjellige typer av ikke-prosessor, ikke-masselager periferenheter som kan koples til IONET-kanalen, så som terminaler 142 skrivere 144, personlige datamaskiner 146, datainnsamligsutstyr 148, modem 150, statiske multipleksere 152 og dess like.

Datamaskinsystemet 100 er forenklet, da det ikke trenger separat lokalt nettverk, flerport adapter, og forskjellige andre muligheter i dets egen karakter inn/ut-kanal grensesnitt reportoar. Videre krever ikke datamaskinsystemet den funksjonaliteten som en nettverksnode har i "LAN"-protokollen for å kommunisere med periferenheter, og på grunn av dette forhold behøver ikke datamaskinsystemet å støtte en protokoll for lokalt nettverk, hvis ikke dette kreves for å kommunisere med andre datamaskinsystemer. I kontrast til dette er den protokollen som skal brukes i samband med IONET kanal 140 primært ment som grensesnitt mot inn/ut-innretninger, og ikke for ressursdeling og grensesnitt mot fjerne operativsystms-funksjoner. Dette medfører at IONET-protokollen er forholdsvis enkel å implementere ved hver fjerne inn/ut-innretning ved hjelp av de distribuerte adaptrene 172.

De distribuerte adaptrene 172 trenger ikke å bli fysisk lokaliseret i særlig nærhet til dtaamaskinsystemet 100, men kan flyttes en betydelig avstand ifra. For eksempel i den foretrukne form av foreliggende oppfinnelse, kan inn/ut-innretningene lokaliseres så mye som over 6 km fra datamaskin syatemet 100. Data som går til og fra inn/ut-innretningene er multiplekset på en enkel seriell kabel 170. Det distribuerte adapteret 172 er plassert i, eller i nærheten av inn/ut-innretningene som de er koplet til. Eksempel på distribuert adapter som er plassert innen inn/ut-innterningene er har vi i den personlige datamaskinen 146, hvor det distribuerte adapteret 172 er illustrert som innsluttet i den samme kassen som den personlige datamaskin 146.

For å framskaffe et mye større datamaskinsystem som har tilkoplet et stort antall inn/ut-innretninger, kan mange IONET-kanaler 140a og 140b koples til det samme datamaskinsystemet som vist i figur 3. Figur 3 illustrerer hvordan denne framgangsmåten kan utvides til støtte for et stort antall inn/ut-innretninger uten tilsvarende å øke antall kabler som går inn og ut av datamaskinsystemet 100. Ved å tilby de lav til middelshastighets kommunikasjon hos datamaskinsystemet i form av IONET-kanaler som vist, og ved å distribuere de funksjoner som normalt forefinnes hos flerports adaptere eller frontprosessorer over til mange distribuerte adaptere, vil mengden som kreves av plass på panelet, og intern kabling i vertsdatamaskinen bli betydelig redusert. Videre er det ikke nødvendig å ha tilgang til datamaskinens kasse for å kople til periferenheter. Kommunikasjonens båndbredde er ikke redusert, da den aggregerte båndbredde er målt ved de mange millioner biter pr. sekund hos medier av type lokalt nettverk, heller enn mange tusen biter pr. sekund som er typisk for lavhastighets kommunikasjonskabler som kommer ut fra et typisk datamaskin-system.

En annen betydlig konfigurasjonsfordel hos foreliggende oppfinnelse er illustrert i figur 4. Konvensjonelle inn/ut-kanaler, enten av masselagertype eller karakter-orientert, kan koples bare til ett datamaskinsystem for å danne kanal for å overføre data mellom datamaskinsystemet og mange periferenheter. På grunn av naturen hos foreliggende oppfinnelse er det mulig å kople mange datamaskinsystemer 100a og 100b til mange inn/ut-innretninger ved hjelp av en enkelt delt IONET-kanal 140 som illustrert i figur 4. Enhver av inn/ut-innretningene 176 kan kommunisere med enten datamaskinsystem 100a eller 100b. Det er ingen begrensning i antall slike datamaskinsystemer som kan koples til IONET-kanalen, andre enn de som muligens kan komme av den aggregerte båndbredden i kanalen, og fysisk begrensning i det antall noder IONET-kanalen 140 kan støtte. Denne fordelen er spesielt viktig, for det ikke er noe fysisk omkopling eller fysisk flerporting involvert. Dette i kontrast til den konvensjonelle bruk av en multikanals bryter på en periferenhet eller en inn/ut-kanal for å kople om mellom konvensjonelle inn/ut-kanaler, og i kontrast til sjaltepanel eller elektriske omkoplingssystemer som er tilgjengelig for å kontrollere tilkoplingen av av periferenheter eller flere kanaler. Slike konvensjonelle innretninger krever økte kostnader og kan minske påliteligheten, på grunn av den ekstra maskinvaren som kreves for å kople den bestemte periferenheten til flere inn/ut-kanaler. Kommunikasjon over IONET-kanalen er kontrollert ved å sende adressesignal, eller tegn, over kabelen, noe som senere vil bli beskrevet i større detalj. Mulighetene for sammen-kopling er dermed basert på programvare og fastvare som opererer i datamaskinsystemet og i de distribuerte adapterene, og tillater hver av inn/ut-innretningene å bli koplet inn eller ut av IONET-kanalen ved å omdirigere tegnene. Da ingen fysisk omkopling kreves, vil ikke en feil ved en av datamaskinsystemene binde enheten som er koplet til dette systemet, da tilkoplingen er logisk. Den foreliggende oppfinnelsen inkorporerer også sikkerhetsrutiner for å tillate en inn/ut-innretning å se ut til å være koplet direkte til en enkelt datamaskin, på tross av at det er mange slike system på samme kabel. Disse fasiliteter er diskutert i større detalj nedenfor.

Den normale konfigurasjonen av datamaskiner i nettverk, som alle har IONET-kanalen, er vist i figut 5. To separate datamaskinsystamer, 100a og 100b, er koplet sammen for å dele ressurser ved hjelp av den enkle kabelen 128 i det lokale nettverket 126. Hver av datamaskinsystemene 100a og 100b har en IONET-kanal, benevt resp. 140a og 140b, til hvilken en kan kople flere inn/ut-innretninger 176. Den muligheten enhver inn/ut-innretning 176 koplet til hver enkelt IONET-kanal har for å få tilgang til ressurser hos andre datamaskinsystemer enn den den enkelte IONET-kanal er koplet til, er en funksjon av den støtte det lokale nettverk har i operativsystemet for hvert enkelt datamaskinsystem, og vil være tilgjengelig i den grad systemprogrammene gir. støtte for den funksjonaliteten.

En annen fordel en kan dra nytte av i foreliggende oppfinnelse, som ikke er spesielt illustrert, men som kan forstås på bakgrunn av figur 4, er muligheten av å bruke signalkabelen 170 for å oppnå funksjonaliteten til både det lokale nettverk og IONET karakter-kanalen. I et slik tilfelle vil programvare innen hver av datamaskinsystemene 100a og 100b støtte både den protokollen mellom datamaskiner hos det lokale nettverk, og IONET-protokollen. Dermed er ett enkelt kablingssystem i stand til å ta vare på den kombinerte trafikken av ressursdelingsaktiviteter hos det lokale nettverket, og de perifere inn/ut-aktiviteten hos IONET-kanalen. Et slikt arrangement vil utnytte mer båndbredde til overføringer innen samme antall tilkoplete inn/ut-innretninger, og bør nyttes når kabelens aggregerte båndbredde er tilstrekkelig til å håndtere den kombinerte belastningen. Når en enkelt kabel er delt, vil dette gi en meget økonomisk måte å kople sammen på. Et slikt arrangement krever til og med mindre kabling ut fra datamaskinen enn i figur 5, der det lokale nettverk og IONET-kanalen er separert.

Den foretrukne form denne oppfinnelsen har blitt implementert i, er i samband med spesielle elektronik-komponenter og protokoll brukt i et lokalt nettverk som er kjent som ARCNET (varemerke), som er et produkt fra patentsøkeren. Det er imidlertid ikke noe restriksjon at den foreliggende oppfinnelse må implementeres med teknologi fra ARCNET lokalt nettverk. Den foreliggende oppfinnelsen kan implementeres med enhver form for lokalt nettverk av tegnsendingstypen. Likevel er oppfinnelsen beskrevet i samband med den foretrukne form som utnytter ARCNET teknologi for lokalt nettverk.

Maskinvare og programvare komponentene hos ARCNET er kommersielt tilgjengelige og godt kjent. Herav har patentsøkeren publisert grundig informasjon angående sitt ARCNET lokalt nettverk, hvor bl.a. ARCNET Designert Handbook, copyright 1983, er tilgjengelig fra patentsøkeren. Videre har Standards Microsystems Corporation, 35 Marcus Boulevard, Hauppauge, New York 11788, markedsført to av de betydelige integrerte kretser som er utnuttet i ARCNET lokalt nettverk og har i tillegg publisert betydelig funksjonsbeskrivelser, som gjør de som behersker disse områder i stand til å bygge et ARCNET lokalt nettverk. Slike beskrivelser kan finnes i Standard Microsystems Corporation data catalouge, publisert i 1985, sidene 193 til 213. På bakgrunn av den relativt velkjente og verdsatte natur hos ARCNET lokalt nettverk, vil ARCNET egenskaper som er brukt i samband med foreliggende oppfinnelse, bli beskrevet nedenfor i forholdsvis forkortet utgave.

ARCNET lokalt nettverk er basert på tengsendingssystem. I et tegnsendingssystem vil enhver node i nettverket vente på å motta en unik kort sekvens av digitale biter, dvs. signal kjent som tegn, fra en foregående node. Mottak av et tegn indikerer at enheten på den noden har lov til å sende eller motta informasjon over nettverket. Nettverket er konstruert med tanke på å sikre at kun et enkelt tegn av gangen er tilstede i nettverket. Etter å ha avsendt informasjonen, sender noden tegnet videre til neste logisk påfølgende node i nettverket hvor prosedyren blir repetert. Hvis en node mottar tegnet og ikke har noe å sende, sender den tegnet videre med en gang. ARCNET lokalt nettverk er arrangert slik at bare aktive noder er tilstede i nettverket til enhver tid. På den måten er noder som ikke er aktiv eller ikke påslått, ikke logisk eller elektrisk delaktig i mottak og sending av tegnet. ARCNET nettverk er i stand til å rekonfigurere seg selv for å gi plass til noder som koples på nettverket, og å elimi-nere noder som faller ut fra nettverket ved dynamisk å justere adressene til nodene som tegnet sendes til. Slike endringer i aktivitetstilstanden hos nodene kan godt skje mens nettverket er i gang, uten å virke inn på nettverket over lenkenivået.

Standard kommunikasjonsmedium som brukes for ARCNET lokalt nettverk er en RG-62 koaksialkabel. Kabelen er benevt 170 i figur 2. Andre kommunikasjonsmedia kan omfatte fiberoptikk, infrarødt samband over eteren, mikrobølge samband og skjermet tvunnet parkabel.

Tilkoplingsmuligheter til koaksialkabelen er forenklet ved å bruke tilkoplings-enheter kjent som trådsentre ("hubs"). Hvert trådsenter inneholder flere porter, som mediumsgrensesnitt kjent som ressurs grensesnitt moduler ("Resource Interface Modules", "RIM") kan tilkoples i den hensikt å kommunisere med hver prosessor, eller som andre kabelledd kan koples til. En "RIM" er tilstede ved hver node. Trådsentre virker som aktive eller passive repeterere mellom kabelseksjoner, og har ingen funksjon i å rute signal. Et trådsenter retransmitterer simpelthen ethvert innkommet signal til hvert av sine utgående porter som et utgående signal. Trådsentre har også blitt beskrevet i den publiserte litteraturen om ARCNET lokalt nettverk, og er også tilgjengelig for kjøp på det kommersielle markedet.

Den fysiske topologien hos ARCNET lokalt nettverk er som på et ubegrenset tre. Den logiske konfigurasjonen av den elektriske forbindelsen i ARCNET lokalt nettverk er som en buss der hver enkelt sendende node sender sitt signal til alle andre noder i nettverket. Kablingen i ARCNET lokalt nettverk er bidireksjonell, dvs. signal flyter alternativt i begge retninger over kabelen. I termer fra mediumtilgangs-kontroll er ARCNET lokalt nettverk en logisk ring basert på aritmetisk økende verdier for å identifisere nettverkets "RIM". Det lokale nettverket rekonfigurerer seg automatisk for å elimimere inaktive noder fra den logiske ringen og for å tillegge nylig aktive noder til den logiske ringen, slik at tegnet blir sendt fra aktiv node til aktiv node basert på "RIM" identifikasjontall. Det blir ikke kastet bort tid på å over-fører tegnet til noder som ikke er aktive. Tegnet kan overføres fra aktiv node til aktiv node uten å ta hensyn til den fysiske lokasjonen eller posisjonen til noden i nettverket. Tegnet sendes mellom alle de aktive nodene på nettverket før den returnerer til den opprinnelige node, og følger således et ring-liknende mønster.

"RIM"-ene virker som de fysisk grensesnittsmidler til kommunikasjonsmediet eller kabelen 170, både i den foreliggende oppfinnelsen og i konvensjonelt ARCNET lokalt nettverk. En slik "RIM", benevnt 178 er inkludert innen ethvert distribuert adapter 172 og i hvert datamaskinsystem 100a som er hengt på sammenkoplingskabelen 170 som vist i figurene 6 og 7. Hver "RIM" 178 inkluderer en sender som sender eller kringkaster signaler på en kabel 170, mange beskjedbuffere som mottar og tar vare på beskjeder eller signal som skal sendes og som blir mottatt over kabelen 170, samt utvelgelses- og annen logikk som er nødvendig for å dele bufferene mellom prosessoren "RIM"-en er koplet til, slik som mikrodatamaskinen 180 som er vist i figur 6, eller kontroll prosessoren 102 vist i figur 7, og å utføre dens øvrige funksjoner. "RIM"-en benytter basisbånds signallering over sammenkoplingskabelen 170. "RIM" 178 er en transformator koplet til sammenkoplingskabelen 170, som kan slås av og på mens det lokale nettverket opereres, med minimal innflytelse på nettverkets operasjon og ingen innflytelse med hensyn på å minske nettverkets ytelse når "RIM"-en er slått av. Hver "RIM" har sin fysiske adresse, ofte referert til som "RIM ID". Denne adressen nyttes til å utføre tegnsendingen.

I tillegg til "RIM" 178, inkluderer hvert distribuerte adapter 172 en mikrodatamaskin 180 og en grensesnittsinnretning 182, som vist i figur 6. Mikrodatamaskinen 180 har tilstrekkelig regnekapasitet til å håndtere den nødvendige datatakt og implementere IONET-kanalens kommunikasjons- og styringsprotokoll. I motsetning til tidligere teknologi sine klasekotrollere eller andre flerports adaptere, inkluder ikke mikrodatamaskinen 170 et operativsystems funksjonalitet, et lokalt nettverks funksjonalitet, eller andre andre flerbrukerfunksjoner. En betydelig besparelse i administrasjon og en økning i nettverkets båndbredde er dermed oppnådd, sammen med en betraktelig nedgang i kostnaden.

Mikrodatamaskinen 180 kan bedre beskrives som en mikrokontroller som simpelthen inneholder en enkel sentralenhet CPU, et mindre leselager ROM, og diverse inn/ut og timerfunksjoner på en enkelt integrert krets. Den foretrukne form nytter en Hitachi HD63B01YO mikrodatamaskin, som ble valgt på grunn av kostnadseffektivitet og plasshensyn. Mer informasjon om denne mikrodatamaskinen kan finnes i Hitachi Microcomputer Data Book No. U71 fra juli 1985 på sidene 358 til 405.

Innretningsgrensesnittet 182 av det distribuerte adapteret 172 er spesiell for den særskilte type inn/ut-innretning 176 som er koplet til det distribuerte adapteret 172. Som et eksempel kan innretningsgrensesnittet 182 være et RS-232 serielt grensesnitt for tilkopling av terminaler og modem, et 8-biters parallelt grensesnitt for tilkopling av rimelige skrivere, et grensesnitt for tilkopling av de mest populære personlig datamaskiner, eller et 8-biters generelt "handshaking" grensesnitt for tilkopling av forskjellige typer av perifert utstyr.

Det distribuerte adapteret 172 kan bygges inn i enhver type innretning som vist i figur 2, eller kan være en separat tilkoplet kasse som er lokalisert fysisk nært opp til innretningen. I alle tilfeller er sammenkoplingskabelen 170 direkte koplet til det distribuerte adapteret 172. Figur 7 illustrerer sammenkoplingen av et datamaskin-system 100a til en kabel 170 hos IONET-kanalen. Den sentrale prosessoren 102 hos datamaskinsystemet er koplet til "RIM" 178, og "RIM"-en er koplet til kabel 170 ved dens node 174. Ved sammenlikning av figurene 6 og 7, kan det klart forstås at IONET sin funksjon hos sentralprosessoren 102 er helt lik funksjonen hos mikrodatamaskin 180, bortsett fra at den sentrale prosessoren hos datamaskinsystemet ikke direkte arbeider mot inn/ut-innretningene. Med andre ord, sentralprosessoren 102 støtter IONET-protokollen og kommuniserer direkte gjennom "RIM"-en over kabelen 170, uten at det kreves bruk av separate protokoller for å oppnå kommunikasjon til og fra kanal-kontrollere og flerports adaptere slik som er vanlig i eldre teknologi. Bare "RIM"-en er nødvendig for å arbeide mot datamaskinsystemer på kabelen, ikke det komplette distribuerte adapteret. Hvis mer enn en IONET-kanal er benyttet fra et enkelt datamaskinsystem 100 (figur 3) kreves det mer enn en "RIM" 178. Figur 8 illustrerer et representativt distribuert adapter 172a i større detalj. Adapteret 172a sender serielle data til, og mottar serielle data fra en konvensjonell inn/ut-

innretning 176a i RS-232 format.

"RIM" 170 inkluderer en hybridkrets 190 som er elektrisk koplet til sammen-koplingsmediet eller kabelen 170. Hybridkretsen 190 er et komersielt tilgjengelig produkt, og er til salgs fra Centralab, Inc., 2601 South Moorland Road, P.O. Box 2145, Milwaukee, Wisconsin 53201; eller fra Micro Technologi, Inc., W141 N5984 Kaul Avenue, Menomonee Falls, Wisconsin 53051; eller fra Zenith CRT and Com-ponents Operations, 100 Milwaukee Avenue, Glenview, Illinois 60025. Hybridkretsen inkluderer en transformatorkopling. En klokkeoscillator 192 gir klokkepulser til transceiveren 194. I tillegg til å kontrollere signal innen det distribuerte adapteret 174a, etablerer også klokkekretsen 192 synkronisering med hensyn på databiter som forefinnes på kabel 170. Transceiveren 194 er en komersielt tilgjengelig del som leveres av Standard Microsystems Corporation og har betegnelsen COM 9032. Transceiveren 194 inneholder en transmitter som sender signal til, og en mottaker som mottar signal fra hybridkretsen 190. Transceiveren 194 gir også klokkepulser til kontrolleren 196, og til mikrodatamaskinen 180 via konduktoren 198.

Kontrolleren 196 er hjertet hos "RIM" 178. Til kontroller 196 er det koplet en rekke brytere 200 som nyttes til å etablere den unike "RIM" identifikasjonsnummer ("RIM ID"). "RIM ID" er synonymt med en node på nettverket der "RIM" 178 er tilkoplet. Kontrolleren 196 inneholder en mikroprogrammert sekvenserer og all logikk som er nødvendig for å styre tegnforsendelser over nettverket og å sende og motta datapakker til rett tid. Kontrolleren 196 etablerer også nettverkskonfigura-sjonen, og rekonfigurerer automatisk nettverket når nye noder legges til eller slettes fra nettverket. Kontrolleren 196 utfører også adressedekodings-funksjoner, syklisk redundanssjekk ("Cyclic Redundancy Check", "CRC") under pakkegenerering og mottak, samt kvittering så vel som andre nettverk funksjoner. Kontrolleren 196 er komersielt tilgjengelig fra Standard Microsystems Corporation med benevnelsen COM 9026.

En standard multiplekset adresse/databuss 202 går ut fra kontrolleren 196, og er det midlet som tar hånd om grensesnittet for data- og adressekommunikasjon. En unidireksjonell adressedriver 204 og en bidireksjonell data transceiver 206 kan også koples til bussen 202 i den hensikt å tillate mikrodatamaskin 100 å kople seg til denne bussen.

Et eksternt pakkebuffer, direktelager "RAM" 208 må omfatte minst 2048 8-biters lagerplass, som er tilstrekkelig for å ta vare på opptil 8 komplette IONET-pakker. Direktelager 208 kan aksesseres av både kontrolleren 196 og mikrodatamaskinen 180. En bufferpeker 210 fins for å identifisere hvilken av de 8 lagerplassene for pakker som skal nyttes ved sendig av pakker, mottak av pakker, og prosessering av pakker ved mikrodatamaskinen 180. Kontrolleren 196 skaffer tilveie alle de nød-vendige signal for tilgangsutvelgelse til direktelager-buffer 208 mellom den selv og mikrodatamaskinen 180. Direktelager 208 er en konvensjonelt digitalt hukommelses-produkt.

Mikrodatamaskin 180 inneholder den nødvendige hukommelses og prosesserings-kraft for å respondere til den styringsinformasjon som fins innen IONET-protokollen, for kommunikasjonsformål som angår styring og datastrøm. Mikrodatamaskinen 180 virker i samband med kontrolleren 196 og transceiveren 194 ved å implementere en sendertilstandsmaskin og en mottakertilstandsmaskin. Sendertilstandsmaskinen styrer sending av signaler fra "RIM" 178 over kabel 170. Mottakertilstandsmaskinen styrer mottak av signaler fra kabel 170 til "RIM" 178. Informasjonen som er kodet inn i de transmitterte signal og dekodet fra de mottatte signal blir lagret i de nevnte områder i direktelageret for pakkebuffer 208.

Mikrodatamaskinen 180 inkluderer en parallell inn/ut port 212 og en seriell inn/ut port 214. Den seriell inn/ut porten 214 er koplet til linjedrivere og mottakere 216 for å kommunisere med inn/ut-innretningen 176a, i dette tilfellet det distribuert adapteret 172a for RS-232 som er vist i figur 8. For grensenitt til andre typer av innretninger kan parallellporten 212 nyttes.

Etter nå å ha beskrevet det generelle arrangement av komponenter i den foreliggende oppfinnelse, kan det nedenfor følgende definisjonssett bedre bli vurdert. Disse definisjoner relaterer seg til mer spesiell egenskaper ved foreliggende oppfinnelse. En "server" er en prosessor som samtidig støtter flere IONET-sesjoner, hvilke er forbindelsen mellom dens subadresser og dens interne, funksjonelle entiteter som dynamisk kan tildeles ved sesjonens initiering. En "klient" er et distribuert adapter eller datamaskin som støtter en eller flere IONET-sesjoner med faste forbindelser mellom dens subadresser og dens interne, funksjonelle entiteter. En "innretning" er en entitet ved en ende av den tovegs kommunikasjonsvegen til en IONET-sesjon. Termene "klient" og "server" brukes her som beskrivende termer relatert til et typisk bruksmønster. Kommunikasjon som gjør bruk av den foreliggende oppfinnelsen kan etableres ved par ev innretninger, enten klient og klient, server og server, eller klient og server. En innretning er identifisert ved en adresse, som er "RIM ID" hos den prosessoren eller det distribuerte adapteret som assosieres med innretningen, og en subadresse, som er de midler som nyttes til å skille mellom kilde- og destinasjonsinnretning for hver enkelt pakke ved hver enkelt prosessor eller distribuert adapter, som kan kople sammen flere innretninger samtidig. En "node" refererer seg til alt som koples til en IONET-kanal ved hjelp av en "RIM". En "sesjon" er en punkt til punkt tovegs virtuell krets etablert mellom et innretningspar. En sesjon består av to "halvsesjoner". En halvsesjon er kommunikasjonsleddet mellom en transmitter ved en node og mottakeren av den korresponderende sesjonsdeltaker ved den andre noden. Det er to halvsesjoner, en i hver retning, for hver hele sesjon som etableres.

Signalene som sendes over kabel 170 styrer kommunikasjonen over nettverket. Disse signal danner en IONET-protokoll for kommunikasjon og styring over IONET-kanalen. IONET-protokollen nytter egenskaper fra ARCNET lokalt nettverk maskinvare, men IONET-protokollen er ikke ARCNET-spesifikk. IONET-protokollen kan operere med sammenlignbar effektivitet og identisk funksjonalitet på ethvert tegn-basert nettverk, men vil muligens operere med redusert effektivitet når andre utvelg-elsesteknikker enn tegnsending blir benyttet.

Den foretrukne form av grensesnittet til nettverket er begrenset bare av behovet for støtte til IONET-protokollen og som grensesbitt til til det "LAN"-mediet som er brukt, som f.eks. ARCNET "LAN". IONET-protokollen opererer uavhengig av noen spesiell innretning eller noe spesielt operativsystem og uavhengig av karakteristikken til noen av inn/ut-kanalene på de forskjellige datamaskinsystemene.

IONET-protokollen er en fullstendig like til like protokoll, som eksisterer på nettverk, transport og sesjonslagene til International Standard Organization (ISO) sin Open System Interface (OSI) referanse modell for kommunikasjon, som vil bli beskrevet nedenfor. Det er ingen master-slave forhold mellom kommunikasjons-entitetene i oppkopling, vedlikehold eller bruk av en sesjon mellom to innretninger. Dette i motsetning til det som er karakteristisk for så å si alle inn/ut-kanaler, der kanal-kontrolleren ved vertsprosessoren er master og den fundamentale kontrolleren av enhver kommunikasjon over kanalen. I IONET-protokollen er det ingen funksjon-ell forskjell når det gjelder styringsfunksjoner eller byte-kommunikasjonen mellom noen enhet, annet enn det som kan ses på som de spesielle muligheter for disse innretninger.

OSI-modellen vist i figur 9 er kan brukes for å beskrive kommunikasjonssystemer, inkludert nettverk. Det er teoretisk mulig å erstatte funksjonaliteten til ethvert av disse laga med ekvivalent funksjonalitet implementert på en annen måte, og alle de øvrige laga vil være upåvirket, og vil operere riktig i systemet. Kommunikasjonen mellom en inn/ut-innretning 176a og en annen inn/ut-innretning 176b over kommunikasjonsmediet slik som kabelen 170 er beskrevet på bakgrunn av de sju lag eller nivå, som hver innebærer et spesielt nivå av funksjonalitet innen kommunikasjonsprotokollen. Det laveste nivå er det fysiske lag 220.

Det fysiske lag 220 innebærer den fysiske forbindelsen til kommunikasjonsmediet 170, og den fysiske signallering slik som spenningsnivå i et elektrisk system, optisk modulasjon i et fiberoptisk system, og høyfrekvens modulasjon i et mikrobølge system, for å ta noen eksempler. I et elektrisk system er det fysiske lag representert ved bitstrømmer som er tilstede på kommunikasjonsmediet.

Det neste lag er lenkelaget 222, som noen ganger er kalt datalenkelaget. Datalenkelaget 222 er det laget der den fysiske leveransen av rådata mellom noder på nettverket blir utført. Den fysiske signalleringsprotokollen, inkludert lenkeinforma-sjon, synkroniseringsinformasjon, informasjon for feilkorrigering, blokkstørrelser, osv. blir ledet i dette laget. I de fleste nettverk er datalenkelaget 222 det lag der de fundamentale kommunikasjonsfeil kan bli detektert og enten korrigert, eller det blir forespurt om retransmisjon. Kommunikasjon mellom et nodepar er avhengig av kom-patible implementeringer av datalenkelagene. Summarisk kan det sies at datalenkelaget etablerer, vedlikeholder og frigir datalenker, og nyttes for feildetektering og fysisk flytkontroll.

Det tredje laget er nettverkslaget 224. Nettverkslaget 224 tar seg av informasjons-ruting gjennom nettverket, inkludert adressering, nettverk initiering, feildetektering og retting, samt veksling, segmentering og blokking av informasjonen. Noen ganger er kvittering for leveranser av rådata utført på nettverknivå, og noen ganger på data-lenkenivå.

Et aspekt ved kommunikasjonen som ikke direkte er berørt av OSI-modellen i et eksplisitt lag, refererer seg til de midler som nyttes for logisk utvelgelse av retten til å sende på det fysiske laget. OSI ville normalt plassere denne utvelgelsen på lenkelaget 222, men det er noen ganger plassert andre steder. Når det gjelder denne utgreiinga, er media aksess kontroll tenkt å være en funksjon for lenkelaget.

Det neste laget er transport laget 226. Transportlaget refererer seg til den trans-parante overføringen av data, ende-til-ende kontroll, multipleksing, avbilding og dess like. Dataleveranser forutsetter pålitelige leveranser, i motsetning til et beste forsøk på å levere de data som må regnes med i de lag under transportlaget. Ved transportlaget, antar man at data har blitt levert på en pålitelig måte, og slike ting som retransmisjon av manglende data, holde orden på de data som er levert utenfor tur, oppretting av transmisjonsfeil, osv. har blitt korrigert på eller under transportlaget. Som en effekt av dette er data som går inn og ut av transportlaget 226 og i de høyere lag, data som er meningsfull til datamaskinsystemet, i motsetning til rådata format-tert for nettverket.

Det femte laget er sesjonslaget 228. Sesjonslaget 228 bruker leveransen av data fra transportlaget til å gruppere datastykker som hører til en gitt aktivitet som er benevt en sesjon. Sesjoner foregår mellom to entiteter ved forskjellige lokasjoner på nettverket. Ved et gitt tidspunkt kan enkeltnoder på nettverket være involvert i flere sesjoner som går til flere noder, og mange sesjoner kan multiplekses over samme nettverk. Likevel er tjenestene i sesjonslaget ment for ende-til-ende leveranser av data som hører til en gitt logisk aktivitet, uten innblanding av data fra andre aktiviteter.

Lag seks er presentasjonslaget 230. Presentasjonslaget 230 er grensesnittet mellom sesjonslaget 228 og applikasjonslaget 232 ved nivå sju. Applikasjonslaget 232 er det laget der de virkelige data gis til, eller mottas fra inn/ut-innretningen 176 ved hver ende av kommunikasjonen. Presentasjonslaget 230 skal hovedsaklig presentere data i en akseptabel form som kan brukes i applikasjonslaget 232 uten å gjøre noe kompro-miss med hensyn til sesjonslaget 228 sin nettverksrelaterte integritet. Presentasjonslaget 230 relaterer seg derfor til datainterpretering, format og kodeinformasjon, mens applikasjonslaget relaterer seg til brukerens applikasjonsprosesser og styringsfunksjoner.

Aktivitetene for både det lokale nettverket og IONET-kanalen sine funksjonaliteter som er diskutert nedenfor eksisterer på sesjonslaget og nedover. Det er ikke tatt med noen videre diskusjoner hva angår presentasjons- og applikasjonslaget, da disse laga er strengt spesifikk for systemet, den fysisk innretning og/eller brukerapplikasjonen.

Bytearrangementet ved en IONET datapakke 240 er illustrert i figur 10, og i figur 11 er IONET pakken brutt ned i de hierarkiske nivå som korresponderer til OSI-modellen illustrert i figur 9. Ikke inkludert i IONET-pakken er et varslingsavbrudd 242 som er generert i en "RIM" av kontrolleren 196 se figur 8, for å identifisere starten av en pakke. Varslingsavbruddet 242 består av seks sekvensielle "1 "-biter, og fins ved det fysiske nivå som vist i figur 11. Den resterende delen av informasjonen i pakken på fysisk nivå 244 er et sett bytes å åtte biter, som inneholder lenkelags-informasjon 245.

I pakken fra lenkelaget 245, sender "RIM" en start av overskrift ("Start Of Heading", "SOH") byte, som er en karakter som markerer starten på en ARCNET-datapakke. Etter "SOH"-byten 246, sender "RIM" en kilde identifikasjon ("Source Identification", "SID") som indikerer "RIM ID" for den noden som sender pakken. De to derpå følgende bytes er repetisjoner av mottaker identifikasjon ("Destination Identification", "DID") byter 250. "DID"-byten 250 indikerer den "RIM ID" til den noden som denne pakken er adressert til. "DID"-byten fins to ganger for feilkontroll og pålitelighetshensyn i et ARCNET lokalt nettverk. Den neste følgende byte 252 er kodet for å identifisere lengden på pakken antall nettverksnivå byter, og er generelt i ARCNET-terminologi referert til som fortsettelsespeker ("Continuation Pointer", "CP"). De avsluttende to bytes i denne pakken er en 16-biters syklisk redundans sjekk ("CRC") 254. "CRC"-byten dannes av "RIM"-en for å detektere transmisjonsfeil.

"SOH" 246 ved starten og "CRC" 254 ved slutten av lenkelagspakken 245 er normalt ikke betraktet som del av ARCNET-pakken, fordi de begge blir generert av og sjekket av nettverkets maskivaregrensesnitt, dvs. ARCNET-kontrolleren 196, og vil aldri forekomme i pakkebufferet (RAM 208, figur 8) til "RIM"-en. De øvrige bytes i overskrifta i lenkelagspakken 245 forefinnes i pakkebufferet, selv om nettverkets maskinvare gir "SID" 248 for utgående pakker uavhengig av verdien i pakkebufferet. "DID" for hver mottaker vil alltid være lik "RIM ID" eller vil være null for kringkastede pakker som mottas av alle noder. Videre blir bare en av de to

"DID" lagret i "RIM"-ens pakkebuffer, slik at bare en "DID" 250 er en del av ARCNETs overskriftsporsjon 258 av IONET-pakken 240. IONET-pakken 240 vist i figur 10 følger denne konvensjonen for illustrasjonens skyld.

Normalt er en typisk ARCNET-pakke 256 bytes, eller mindre lang. Det er imidlertid mulig å kommunisere over ARCNET lokalt nettverk med lange datapakker med lengde opp til 512 bytes. I modus for lange datapakker, er "CP" 252 to bytes lang, noe som gjør lenkelagsoverskrifta seks bytes lang heller enn fem som vist.

Nettverklagsinformasjonen 257 som er etter "CP" 252 og før "CRC" 254 er informasjon som er avsendt fra kontrolleren 196 (figur 8) opp til nettverkslagets tolking vha. lavnivå programvare eller fastvare tilhørende datamaskinsystemet eller det distribuerte adapteret.

Nettverkspakken 257 starter med en sju bytes lang overskrift med byte for systemkoden ("System Code", "SC") 256. "SC"-byten 256 er en alminnelig egenskap ved alle ARCNET-pakker og indikerer type pakke. Systemkoden brukes for å identifisere og skille forskjellige type kommunikasjonsprotokoller som kan benyttes samtidig.

Når "SC" 256 i ARCNET-overskrifta identifiserer en IONET-pakke gjennom den unike IONET-pakkens kode, danner de følgende ti bytes 260 IONET-overskrifta for IONET-pakken 240. IONET-overskrifta 260 gir nettverksnivå og transportnivå informasjon og indikerer hvordan det gjenstående dataområde 262 skal deles mellom administrativ informasjon 264 og bytestrøminformasjon 266.

Delingen av dataområdet 262 i en administrativ porsjon 264 og en porsjon med bytestrøm 266 tillater det som kalles "out-of-bands" signallering, ved at det skilles mellom den administrative informasjonen som brukes for å kontrollere inn/ut-innretningen eller det distribuerte adapteret eller rapportere status fra inn/ut-innretningen eller det distribuerte adapteret, fra bytestrøminformasjonen 266 som nyttes for å kommunisere informasjon til og fra inn/ut-innretningen. Den administrative informasjonen 264 kan gis av, inspiseres av, eller modifiseres av IONET-kontrollerte komponenter, men bytestrøminformasjonen 266 er alltid tatt hånd om på en transparent måte, og blir derfor levert til mottakerens inn/ut-innretning umodifisert fra den kilde-verdien som var der når den ble sendt.

De først seks bytes av IONET-overskrifta 260 er en del av nettverkpakken 257. Disse bytes er i rekkefølge en senderstatus byte ("Transmitter Status Byte", "TXSB") 268, en mottakerstatus byte ("Receiver Status Byte", "RXSB") 270, en to-bytes kildesubadresse "Source Subaddress", "SSA" 272, en to-bytes mottakersubadresse ("Destination Subaddress", "DSA") 274, de resterende fire bytes hos IONET-overskrifta 260 fins innen transportnivåpakken 276. Den første byten i transportnivåpakken indikerer pakkefunksjonen ("Packet Function", "PFN") 278. Den derpå følgende byte 280 er ennå ikke i bruk, men er reservert for framtidige utvidelser. Den tredje byten er en administrativ lengdeverdi ("Administrativ Length Value", "ADL" eller "ADLNG") 282. "ADL" har til funksjon å identifisere lengden av den administrative informasjonen 264 av dataområdet 262. Den siste byten 284 er en bytestrøm lengdeverdi ("Byte Stream Length Value", "BSL" eller "BSLNG") 284. "BSL" identifiserer den lengde bytestrømmen 266 har av dataområdet 262. Både "ADL" 282 og "BSL" 284 for den sammenlagte lengden av den administrative informasjonen 264 og bytestrømsinformasjonen 266 kan være mindre enn den totale lengden til nettverksnivåpakken 257. I slike tilfeller er ikke de resterende bytes i nettverksnivåpakken 257 ut over de som er definert for dataområdet 262 ikke i bruk. Lengden av dataområdet 262 kan bli opp til 242 bytes i kortpakke-modus eller opp til 497 bytes i langpakke modus. Når lange pakker benyttes, er "CP" 252 to bytes lang og både ARCNET-overskrifta 258 og IONET-overskrifta 260 er utvidet for en ekstra byte mer enn det som er illustrert i figur 10.

Flere detaljer angående ARCNET-overskrift 258 og IONET-overskrift 260 er illustrert ved diagrammet vist i figur 12, som viser navnet til hvert felt innen hver overskrift, den bitvise oppsetningen fra den minst signifikante bit til høyre til den mest signifikante bit til venstre i hvert felt, og gir et sammendrag for hvert felt.

Kildeidentifikasjonen ("SID") for hvert felt i ARCNET-overskriften 258 for hver innkommet pakke blir sjekket ved "RIM"-en ved hver node hver gang en sesjon er i gang. Alle pakker som sendes av den aktive sesjonspartneren blir akseptert for interpretering og prosessering. Alle pakker som mottas fra "RIM"-ene fra andre noder, bortsett fra de som inneholder spesielle funksjoner vedrørende nivåkontroll, blir avvist, og "RIM"-mottakeren blir øyeblikkelig igjen gjort klar. Når ingen sesjon er i gang, vil alle innkomne pakker bli interpretert, men bare de som inneholder spesiell nettverks- og transportnivå kontrollfunksjoner som relateres til etableringen av en sesjon og oppsettingsparametre eller statistikk blir akseptert for prosessering.

Mottakeridentifikasjonen ("DID") 250 i ARCNET-overskrifta 258 er enten lik "RIM ID" for denne noden, eller er null for kringkastede beskjeder. "RIM" som bruker IONET-kanalen er alltid konfigurert for å motta kringkastede beskjeder. Bare lokale kommandoer, beskrevet nedenfor, blir akseptert som kringkastet av innretninger. Enhver annen kringkastet beskjed som mottas, selv om de har IONET systemkode ("SC"), vil bli avvist av innretningen.

Fortsettelsespekeren, ("CP") 252 i ARCNET-overskrifta brukes for å bestemme lengden av en IONET-pakke. "CP" er en byte lang for kortpakkemodus, og inneholder pakkelengden subtrahert fra 259. "CP" er to bytes lang, med første byte satt til null, og den andre byten satt til pakkelengde subtrahert fra 516 for langpakkemodus.

Systemkoden ("SC") 256 for ARCNET-overskrifta 258 kan være enhver spesiell kode som identifiserer IONET-protokollen, og eksempel på en slik koding er illustrert i figur 12. Innkomne pakker med andre systemkoder (andre enn en diagnostisk systemkode) blir avvist av alle klienter og hvis de blir motart, skjer dette av alle serverne og ved andre protokollkoder.

IONET-overskrifta 260 brukes av alle sender- og mottakertilstandsmaskiner for å kontrollere bytestrømskommunikasjonen over nettverkets kommunikasjonsmedium, for å dirigere pakkeinnhold til den korrekte inn/ut-innretning, og for å bestemme innholdet i dataområdet 262 i pakken.

Byte for senderstatus ("TXSB") 268 i IONET-overskrifta 260 inneholder informasjon relatert til den alminnelige bruken av IONET-pakken og status til den senderen som sendte pakken. Som vist i figur 12, er umiddelbar-feltet i "TXSB"-byten kodet for å skille mellom pakker av umiddelbar prioritet (feltet =1) og pakker av normal prioritet (feltet=0). Pakker for ekspeditt levering refereres til som umiddelbare pakker. Utgående umiddelbare pakker sendes før ventende pakker av normal prioritet, og innkomne umiddelbare pakker vil bli prosessert så snart de blir mottatt, før pakker av normal prioritet som venter i mottaksbufferet og (typisk) før resten av de normalpiroriterte pakker som er underveis (hvis noen) når de umiddelbare pakkene blir motart.

Operasjonsfeltet hos "TXSB" inneholder en kode for hvilken bruk IONET-pakken skal gjøre av transportnivået. De bruk av tranportnivået som kan kodes i operasjonsfeltet er: "NOP", brukes for holde-levende beskjeder; "IDLE", som indikerer en sender venter ("Transmitter Waiting", "TW") status; "DATF", som indikerer en sender aktiv ("Transmitter Active", "TA") eller umiddelbar sender aktiv ("Immidiate Transmitter Active", "ITA") status på den siste (eller eneste) pakke i transmisjons-gruppen, hvor "PFN" 278 feltet kontrollerer bruken av dataområdet; "DATAI", som indikerer en "TA" status på første, eller umiddelbare pakker i sendergruppen, hvor "PFN" 278 feltet kontrollerer bruken av dataområdet; "CONTROL COMMAND" som er videre kodet i funksjonsfeltet i "TXSB"-byten.

Sekvensnummeret eller funksjonsfeltet i "TXSB"-byten 268 inneholder sekvensnummeret hos den pakken som sendes når operasjonsfeltet er kodet for alle funksjoner bortsett fra "CONTROL COMMAND" og "CONTROL REPLY" funksjonene. Når operasjonsfeltet er kodet for "CONTROL COMMAND" og "CONTROL REPLY", er kontroll funksjonen kodet i funksjonsfeltet hos "TXSB" som vist i det følgende diagram:

Ved referanse til overstående diagram, er en "CONTROL COMMAND" tilstede i operasjonsfeltet hos "TXSB" 268 når "TXSB" verdien starter med "E" eller "6" på disgrammet. Funksjonen en oppnår ved den spesielle "CONTROL COMMAND" er indikert i "KONTROLL FUNKSJON" kolonnen. Datafunksjoner kodet i operasjonsfeltet hos "TXSB" er indikert ved verdier som begynner med "4", "5" eller "C". Disse fire funksjonene, avsluttende dataoverføring ("DATAF"), initierende/mellomliggende dataoverføring ("DATAI"), "flush" buffere, kjør utvidet diagnostistikk og rapporter status, er kodet i typekode-feltet hos "PFN"-byte 278 i tillegg til "TXSB". "LNG"-feltet viser lengden som kreves eller er tillatt for hver type kontrollfunksjon. Kolonne "mottatt av" indikerer klassen av innretning, Enten klient ("C"), server ("S") eller begge ("A"), som kan ta imot hver type IONET-pakke. "SESJ."-kolonnen indikerer om en kommmando aksepteres både i og utenfor en sesjon indikert ved "E", eller om kommandoen aksepteres bare utenfor en sesjon, indikert ved "O", eller om kommandoen aksepteres bare innenfor en sesjon, indikert ved en "I". "MOD."-kolonnen indikerer om pakken må sendes som en umiddelbar pakke, indikert med en " I", om pakken må sendes Som normal prioritet, indikert med en "N", eller om pakken kan sendes i enten normal eller umiddelbar modus, indikert med en "E". I tilfellet for så å si alle kontroll kommandoene, blir en svarpakke generert av mottakende innretning og blir sendt tilbake til den innretningen som sendte den opprinnelig kontrollkommandoen. Kolonnene for "TXSB", "PFN", og "LNG" under "SVAR" gir kontrollkoder og lengder for kontrollsvar-funksjoner sendt som respons til de forskjellige kontrollkommandoene.

Mottakerstatus byten "RXSB" 270 i IONET-overskrifta inneholder informasjon som angår status til mottakertilstandsmaskinen ved den innretningen som sendte pakken. Den høyeste ordens bit eller umiddelbar-feltet settes for å skille mellom kvittering av umiddelbare pakker og normale pakker. Kvitteringsfeltet ("Acknow-ledge", "ACK") koder kvittering til den siste pakken som er mottatt av innretningen slike som "NOP"; "BUSY", som indikerer en mottaker venter ("Receiver Waiting", "RW"); eller en umiddelbar mottaker venter ("Immediate Receicer Waiting", "IRW") status; og "READY", som indikerer en mottaker aktiv ("Revceiver Activ", "RA") eller en umiddelbar mottaker aktiv ("Immediate Receiver Active", "IRA"). Feilfeltet blir satt lik "1" hvis en detekterbar intern feil lokalt i klientens maskinvare eller fastvare har oppstått, og blir ellers satt til null. Sekvensnummerfeltet inneholder sekvensnummeret til den pakken som det kvitteres for.

Kildesubadressen ("SSA") 272 for IONET-overskrifta identifiserer den spesielle kildeinnretningen ved noden som pakken er sendt fra. Mottakersubadressn ("DSA") 274 identifiserer en spesiell mottakerinnretning ved den noden som skal motta denne pakken.

Pakkefunksjonen "PFN" 278 definerer bruken av dataomådet 262 (figur 10) i IONET-pakken i de tilfeller "TXSB" indikerer at det er "data"-pakke ved en opera-sjonskode "DATAI" eller "DATAF". Typekodefeltet "PFN" 278 koder generelt bruk av pakken for å indikere dataoverføring, når dataområdet inneholder bytestrøm og adminiatrative data for å brukes av inn/ut-innretningen; eller en klient kontroll kommando, når dataområdet inneholder kontrollinformasjon som nyttes av klientens fastvare; eller et klient kontroll svar, når dataområdet inneholder kontrollinformasjon sendt som svar på en kontrollforespørsel.

Bitene benevnt "ASL" og "ADL" hos "PFN" 278 brukes for å ta vare på de mest signifikante biter av verdien til lengden for "ADLNG" 282 og "BSLNG" 284 bytene beskrevet nedenfor. Funksjonskodefeltet hos "PFN" 278 er alltid satt til null for dataoverføringsfunksjoner. For klient kontroll kommandoer og klient kontroll svar er klientfunksjonen kodet for å indikere "flush" bufferene, kjør utvidet diagnostikk, og funksjoner for å rapportere status som tidligere er identifisert i overstående diagram.

Bytene for adresselengden ("ADLNG") 282 og bytestrømslengden ("BSLNG") 284 danner en dataområde-beskrivelse. Databeskriveren definerer bruken av dataområdet 262 (figur 10) av IONET-pakken. Verdien innen "ADLNG"-feltet 282 spesifiserer lengden av den administrative informasjonen 264 (figur 10). Hvis den administrative informasjonen har en lengde forskjellig fra null, starter bytestrømsområdet umiddelbart etter databeskriveleren 282 og 284 og strekker seg ut det spesifiserte antall bytes. Bit 4 i "PFN"-byten 278 fungerer som den mest signifikante bit i "ADLNG" 282 byte for å tillate "ADLNG"-verdier over 255 for bruk ved modus for lange pakker.

Tallet som er kodet i "BSLNG"-feltet 284 spesifiserer den lengden som byte-strømmen 266 har av av dataområdet 262. Hvis verdien i "BSLNG" er forskjellig fra null, starter bytestrømsområdet fra byten etter det administrative området, eller følger dataområdebeskriveren 282 og 284 hvis "ADLNG"-feltet 282 er null. Byte-strømmen strekker seg ut det antall bytes spesifisert i feltet 284. Bit 5 hos "PFN"-byte 278 fungerer som den mest signifikante bit i lengdeverdien spesifisert i "BSLNG"-feltet 284 for å gi rom for "BSLNG"-verdier større enn 255 for bruk i modus for lange pakker.

De mest vanlige pakkene som sendes over IONET-kanalen er de som overfører bytestrømsdata for bruk ved mottakerens inn/ut-innretning. Kontrollfunksjonspakker er slike hvis innhold blir interpretert innen støtte-programvare eller fastvare hos IONET server eller IONET klient, Og er ikke sendt av inn/ut-innretningen. IONETs kontrollfunksjonspakker er de indentifisert i overstående diagram og er identifisert i "TXSB" 268, som beskrevet i forbindelse med figur 12.

IONETs kontrollfunksjonskommandoer og -svar er tilgjengelig på flere nivå. Nettverksnivåets kontrollfunksjoner relaterer til noder på IONET-kanalen og er uavhengig av sesjonsaktiviteten. Transportnivåets kontrollfunksjoner nyttes til å etablere, styre og avslutte sesjoner. Sesjonsnivåets kontrollfunksjoner nyttes for å styre grensesnittet til inn/ut-innretningene, og er bare brukbare når en sesjon er i gang, med de unntagelser som er anført. Sesjonsnivå bytestrøm funksjoner overfører data, kontroll og statusinformasjon til og fra de tilkoplete inn/ut-innretningene.

Kontrollkommandobeskjeder blir alltid sendt ved hjelp av korte IONET-pakker. Alle "CONTROL COMMANDS" krever vedkommende mottaker å sende tilbake et "CONTROL REPLY". Med andre ord, kontrollfunksjoner medfører særskilt "handshake" mellom sendertilstandsmaskinene for de kommuniserende innretningene. Denne "handshake" involverer ikke mottakertilstandsmaskinene. De generaliserte detaljer som gjelder for hver "CONTROL COMMAND" og "CONTROL REPLY" følger nedenfor.

Den positive kvitteringen til en "CONTROL COMMAND" i form av et "CONTROL REPLY" er alltid nødvendig, uavhengig av sendepakkens nummer. Ingen flere overføringer (bortsett fra nye forsøk) blir gjort før det korresponderende "CONTROL REPLY" er mottatt. Sekvensnummerering er hverken påkrevd eller brukt for kontrollfunksjonspakker. Eksempel på typer av avsluttende koder som kodes inn i det administrstive området 264 av dataområdet 262 av hver IONET-pakke 240 som sender kontrollsvaret, kan bl.a. være som følger: vellykket avslutning av kontrollfunksjonen; kontrollfunksjonen er ikke støttet av mottakerinnretningen; kontrollfunksjonen er avvist på grunn av mottakerens status; kontrollfunksjonen er avvist på grunn av at innretningen ikke er i sesjon; kontrollfunksjonen er avvist på grunn av at innretningen allerede er i sesjon; kontrollfunksjonen er avvist på grunn av at konfigurasjonslåsen for innretningen er satt; og det er spesifikasjonsfeil i "CONTROL COMMAND" -parametre.

Som vist i foranstående diagram, omfatter nettverksnivåets kontrollfunksjoner også rapporter innretningsparametere, rapporter statistikk, rapporter grensesnittsparametere, sett innretningsparametere, sett grensesnittsparametere, og lokaliser. Det fins også en nullfunksjon, ikke vist i overstående diagram, som ignoreres av mottakeren uten at det blir generert hverken en feil eller et svar. Disse nettverksnivå kontrollfunksjoner blir akseptert av IONET sine noder til enhver tid, enten en sesjon er i gang eller ikke. Disse kontrollfunksjonene trenges ikke å stamme fra "SID" til den aktive sesjonspartneren for å bli akseptert under en sesjon.

"CONTROL COMMAND" for rapporter innretningsparametere fører til at IONET-innretningen genererer en "CONTROL REPLY" pakke som inneholder informasjon om type og status på inn/ut-innretningen. Kommandoen for rapporter

innretningsparametere blir gjenkjent av alle innretninger, og blir akseptert enten en sesjon er i gang eller ikke, og blir akseptert fra enhver kilde om innretningen er i en sesjon, og ikke bare fra sesjonspartneren. Noe av den informasjonen som blir rapportert relaterer til attributtene til noden. Denne informasjonen blir rapportert på en lik basis for alle innretinger. Kommandoen rapporter innretningsparametre blir ikke akseptert fra kringkastede pakker på grunn av den store mengden av trafikk som da vil bli generert, mangelen på kringkastingsmuligheter som refererer seg til subadresser, mangelen på evne til å bestemme om en har mottatt respons fra innretninger. Kommandoen for rapporter innretningsparametre blir sendt som en umiddelbar pakke.

Formatet til pakken for det "CONTROL REPLY" som blir sendt som respons til en "CONTROL COMMAND" for rapporter innretningsparametre, kan med fordel

inkluderes i den administrative informasjonsseksjonen 264 av dataområdet 262 (figur 10): en indikasjon på avslutningskoden beskrevet overfor, typekode brukt for å identifisere klienter og ervere og typekoden til inn/ut-grensesnittet 182 (figur 6) assosiert med innretningen, en pakkelengde, sendepakkenummeret, som indikerer maksimum antall "DATAI"-pakker som kan sendes før en "DATAF"-pakke kreves, og en byte for sesjoninitieringstype. Byten for sesjonsinitieringstype indikerer en begrensning på en IONET-innretning som avgrenser dens kommunikasjon til på forhånd bestemte klienter og servere i en på forhånd bestemt sesjon. Denne type restriksjon på kommunikasjonen er med fordel tatt med i den hensikt å begrense tilgangen til spesielle innretninger og kreve spesielle sikkerhetsnivåer for å få til kommunikasjon mellom særskilte innretninger.

Kontrollkommandoen rapporter statistikk fører til at den innretningen kommandoen er adressert til vil generere en "CONTROL REPLY" pakke som inneholder statistisk informasjon som er samlet inn av innretningen. Denne kommandoen blir gjenkjent av alle noder på subadresse null, og kan gjenkjennes av alle innretninger. Denne kommandoen blir akseptert enten en sesjon er i gang eller ikke, og blir akseptert fra enhver klide når innretningen er i en sesjon, ikke bare fra sesjonspartneren. Noe av den informasjonen som blir rapportert relaterer til attributter vedrørende noden, og blir rapportert på samme form for alle innretninger på noden. Denne kommandoen blir ikke akseptert fra kringkastede pakker på grunn av den store nettverkstrafikken som da blir generert, mangelen på kringkastingsmuligheter som refererer seg til subadresser, og mangelen på evne til å bestemme om alle responser har blitt mottatt. Denne kommandoen blir sendt som en umiddelbar pakke.

"CONTROL COMMAND" rapporter grensesnittparametre, medførere at klient-innretningen genererer en "CONTROL REPLY" pakke som inneholder informasjon om grensesnittstatus, og tilsvarende modal status hos innretningen. Informasjonen blir rapportert fra det parametersettet som ligger lagret i direktelageret som er assosiert med innretningen, og som på det tidspunkt er i bruk av innretningen. Disse verdiene kan i spesielle tilfeller være forskjellig fra de verdier som er lagret i

klientens ikke-flyktige lager. Denne kommandoen blir gjenkjent av alle klienter på en måte som er spesiell for hver klient, er avvist av alle servere, er akseptert av klienter enten en sesjon er i gang eller ikke, og er akseptert fra enhver kilde når en sesjon er igang, og ikke bare fra sesjonspartneren.

Kommandoen for rapporter grensesnitt parametre må sendes som en umiddelbar pakke for alle andre enn sesjonspartneren, og kan sendes i enten umiddelbar eller normal modus av sesjonspartneren. Spesielle bytes i den administrative informasjons-området 264 av dataområdet 262 (figur 10) av IONET-pakken kan settes av til kom-munikasjonsverdier som er forskjellig fra de parametrene som er lagret i direktelageret.

"CONTROL COMMAND" sett innretningsparametre fører til at klienten lagrer nye verdier i det ikke-flyktige lageret. Denne kommandoen blir bare akseptert av klientinnretninger og bare når konfigurasjonslåsen ikke er satt, og blir da akseptert fra enhver kilde, ikke bare sesjonspartneren (hvis noen). Denne kommandoen må sendes som en umidddelbar pakke.

I tillegg til nevnte informasjon innen den administrative informasjonsseksjonen av dataområdet i IONET-pakken, kan det være bytes for å identifisere typen av ekstern enhet, et innretningsnavn, typen av innretning som initierte sesjonen, innretningens typespesifikke tjeneste-klasse, identifikasjonen av en på forhånd bestemt partner eller passord for fjernsesjon, samt status for konfigurasjonslåsen.

"CONTROL COMMAND" sett grensesnitt parametre fører til at klienten setter nye verdier for grensesnitt kontroll og tilsvarende modal status. De nye verdiene blir anvendt for grensesnittet, og blir lagret i klientens direktelager. Disse verdiene kan

også lagres i klientens ikke-flyktige lager. Denne kommandoen kan også nyttes for å hente fram verdier fra det ikke-flyktige lageret og inn i direktelageret.

Kommandoen sett grensesnittparametere blir gjenkjent av alle klienter på en innretningsspesifikk måte, blir avvist av alle servere, blir alltid akseptert av klienter fra sesjonspartneren og blir akseptert av klienter fra enhver kilde enten den er i en sesjon eller ikke, hvis konfigurasjonslåaen ikke er satt.

Kommandoen sett grensesnittparametere må sendes som en umiddelbar pakke for alle andre enn sesjonspartneren, og kan sendes i enten umiddelbar eller normal modus av sesjonspartneren. Tilleggsinformasjon i den administrative informasjonsseksjonen av IONET-pakken relaterer seg til kontroll fra direktelager eller ikke-flyktig lager for å skrive parametre fra pakken inn i direktelageret eller inn i både direktelageret og det ikke-flyktige lageret og for å hente ut parametre fra ikke-flyktig lager og inn i direktelageret. Annen informasjon i den administrative informasjonsseksjonen relaterer seg til inretningsparametre som er typespesifikk.

"CONTROL COMMAND" lokaliser kan sendes som en kringkastet beskjed av innretninger som prøver å etablere en sesjon i den hensikt å bestemme "RIM" identifikasjons-nummeret og subadressen hos en ønsket mottakerinnretning som forsøkes å lokaliseres ved bruk av det navnet den har fått tildelt. I det blir mottatt flere svar, blir alle untatt det første ignorert. Kommandoen lokaliser blir gjenkjent av alle noder med subadresse null, er akseptert enten en sesjon er i gang eller ikke, blir akseptert fra enhver kilde når innretningen er i en sesjon, og ikke bare fra sesjonspartneren. Kommandoen lokaliser er den eneste kontrollkommandofunksjon som blir akseptert fra kringkastede pakker.

En lokaliseringskommando må sendes til subadresse null hos mottakeren. Kildesubadressen i kontrollsvarpakken identifiserer den spesielle innretningen på den responderende node som har blitt lokalisert ved å sende dens identifikasjonsnummer. Hvis flere innretninger ved den responderende node stemmer med navnet, blir flere svarpakker generert. Hvis ingen innretninger ved nodene som mottar lokaliserings-pakken stemmer med navnet, blir ingen svar generert.

Det at et tidsintervall går ut mens en venter på et svar på en lokaliseringskommando indikerer at det ikke eksisterer noe aktiv innretning som har et navn som stemmer. Lokaliseringskommandoen må sendes som en umiddelbar pakke. Navnet på den responderende pakken blir kodet inn i det administrative informasjonsseksjonen av IONET-pakken. Lokaliseringskommandoen inneholder også en ønsket tjeneste klasse. Hvis verdien er null, må bare navnet være lik, ellers må både navn og tjenesteklasse være lik. Avslutnings-koden i svaret til en lokaliseringskommando skiller mellom det tilfellet der innretningen er i stand til å akseptere en tilkoplingskommando for den spesifiserte tjenesteklasse, og det tilfellet at innretningen ikke er i stand til å akseptere en slik tilkoplingskommando.

Som vist i overstående diagram, omfatter kontrollkommandoene på transportnivå oppkopling, videresending, nedkopling, redirigering og resynkronisering.

"CONTROL COMMAND" for oppkopling etablerer en sesjon, hvis ingen allerede er i gang og blir avvist hvis den mottas når en sesjon allerede er i gang. Enten klient eller server kan initiere sesjonen ved å sende oppkoplingskommandoen. Oppkoplings-forespørsler til servere skal generelt sendes til subadressen som returneres som svar

til en lokaliseringskommando etter den ønskede sesjonspartnerens navn (eller til subadresse null). Serveren kan redirigere sesjonskommunikasjonen til an annen subadresse ved å sende den passende verdien for kilde subadressen ("SSA") 272 (figur 12) feltet i svarpakken. Sesjonstrafikken skal så dirigeres til den mottakersubadressen som mottas fra "SSA"-feltet i svarpakken.

Oppkoplingskommandoen må sendes som en umiddelbar pakke. Helst skal den administrative informasjonsseksjonen i "CONTROL COMMAND" pakken for oppkopling inneholde informasjon angående type enhet, dens maskinvare og fastvare eller programvare revisjonnummer, hvilken versjon av protokollen som den tilbyr, dens maksimale subadresse, dens pakkelengde og teller for sendte pakker, dens minimum innkomne pakkers lengde, tiden før en pakke må sendes av en klient, type eksternt utstyr for kilden, et innretningsnavn for kilden, sesjonsinitieringstype for kilden, tjenesteklasse for kilden, og passord for sesjons-initieringen.

Hvis oppkoplingskommandoen blir akseptert, vil en "CONTROL REPLY" pakke bli generert enten oppkoplingsforespøxselen er vellykket eller ikke. Hvis avslutnings-kodefeltet indikerer at sesjonen ikke er blitt vellykket etablert, vil avslutningskoden spesifisere årsaken for feilen. Noen av de årsakene som kan spesifiseres i avslutningskoden for feil i vellykket etablering av sesjonen er kontrollfunksjonen er blitt avvist fordi innretningen er allerede i en sesjon, det er en spesifikasjonsfeil i kontrollfunksjonens parametre, den svarende innretningen støtter ikke den spesielle protokollversjonen eller maskinvare revisjonsnummer eller revisjonsnummer for fastvare eller programvare som er ønsket, innretningen er av utilgjengelig tjeneste-klasse, innretningen er ikke konfigurert for fjern initiering, eller det kan være feil passord eller navn. I tillegg kan den øvrige administrative informasjonen i "CONTROL REPLY" pakken relatere til hvilken protokollversjon som skal nyttes, pakkelengden som skal nyttes, teller for sendte pakker som skal nyttes, maksimal lengde på innkomne pakker, og til den før en må sende en innkommet pakke.

"CONTROL COMMAND" videresend konfigurerer en server innretning til å være en videresender av pakker for lenking mellom nettverk. Når videresendingen først er etablert, vil innretningen hverken tolke eller kvittere for IONET-pakker, men simpelthen sender dem videre i den hensikt å skape et mellomledd. Siden det ikke er mulig å kommunisere med en videresendende innretning, må alle konfigurasjoner av av denne innretningen gjøres før avsendelse av videresendings-kommandoen. Den

videresendende innretning opererer ikke tilstandsmaskiner for transportkontroll, men overvåker reverskanalen for å se etter et "CONTROL REPLY" for nedkopling for å vite når videresendinga skal avsluttes. For å unngå tap av ressurser når kommunikasjonen forsvinner på en ureglementær måte, vil videresendinga bli nedkoplet, og innretningen går inn i en uoppkoplet tilstand, hvis ingen kommunikasjon er mottatt i noen retning etter et tidsintervall spesifisert i videresendingskommandoen som etablerte forbindelsen.

Forespørsler om videresendinger skal generelt sendes til subadresse null. Den som skal videresende kan omdirigere kommunikasjonen til en annen subadresse ved å sette en passelig verdi i "SSA"-feltet 272 (figur 12) hos svarpakken. Kommunikasjonen skal så senere dirigeres til den mottakersubadressen som fås fra "SSA" -feltet i svarpakken.

Videresendingskommandoen blir avvist hvis den mottas når en sesjon er i gang. Innretninger som ikke er i stand til å fungere som videresendere av pakker (omfatter alle klienter) vil alltid avvise denne kommandoen. Enten klienter eller servere kan initiere videresending ved å sende en videresendongskommando. Videresendings-kommandoen må sendes som en umiddelbar pakke. Den administrative informasjonsseksjonen av IONET-pakken for videresending omfatter fortrinnsvis navnet på det mottakende nettverket, navnet på den ønskede innretningen på mottakersida, den ønskede klasse av tjenester, og kommunikasjonens tidsfrister.

Mottakerinnretningen for den videresendte kommandoen utfører en lokaliserings-funksjon på det ønskede nettverk etter den angitte mottakerinnretningen for å bestemme "RIM ID" og subadresse som kommunikasjonen skal videresendes til.

Hvis videresendingskommandoen blir akseptert, blir en svarpakke generert enten forespørselen om videresending er vellykket eller ikke. Hvis feltet for avslutnings-kode inneholder noe kode som indikerer at videresendingen ikke er vellykket etablert, vil avslutningskoden spesifisere årsaken for feilen. Årsakene for feilen kan være de samme som de som tidligere er beskrevet.

En "CONTROL COMMAND" for nedkopling avslutter en sesjon. Nedkoplingskommandoen blir avvist hvis ingen sesjon er i gang. Både klienter og servere kan initiere en nedkoplingskommando. Nedkoplingskommandoen må sendes som en umiddelbar pakke.

En "CONTROL COMMAND" for omdirigering sendes samtidig til sesjons-partnerene til to aktive sesjoner fra en node som ønsker å omdirigere trafikken til disse to sesjonene slik at partnerne i disse to sesjonene kommuniserer med hverandre, og ikke lengre med den noden som sender omdirigeringskommandoen. Denne kommandoen må sendes som en umiddelbar pakke. Den administrative informasjonsseksjonen av omdirigeirngspakken omfatter den nye mottakeridentifikasjonen, og den nye mottakerens subadresse. Avslutning av en omdiriggeringskommando involverer

resynkronisering, som beskrevet nedenfor.

En "CONTROL COMMAND" for resynkronisering fører til at sender- og mottakertilstandsmaskinene på hver ende av en sesjon tilbakestiller sin status ved etableringen av en sesjon. Dette åpner for muligheten til at kommunikasjonen kan reetableres uten nedkopling og gjenoppkopling i de tilfeller hvor sekvensnummer eller annen synkronisering mellom de to er gått tapt.

Enten klienter eller servere kan sende resynkroniseirngskommando når en sesjon er i gang. Resynkroniseirngskommandoen blir avvist hvis ingen sesjon er i gang. Resynkroniseirngskommandoen må sendes som en umiddelbar pakke. Kontrollfunksjonene for sesjonsnivå omfatter "flush" buffere, kjør utvidet diagnostikk, og rapporter status. Kontrollfunksjonene for sesjonsnivå er tolket klientenes grensesnittkontroll i fastvare. Detaljene i de fleste av disse kommandoene er typespesifikke, og bare deres felles aspekter er diskutert nedenfor. Bemerk at disse kontrollfunksjonene på sesjonsnivå sendes i pakker som der "TXSB"-verdien indikerer dataoverføringer ("DATAF"), men verdien på "PFN" indikerer klient kontroll-forespørsler og klient kontroll svar.

Kontrollfunksjonen "flush" buffer fører til at mottekeren forkaster alle pakker eller deler av pakker tilstede i mottakerbufferet innen det distribuerte adapteret, eller lavnivå programvare. Kommandoen "flush" buffer er akseptert av enhver innretning som har en sesjon igang, og er ignorert når ingen sesjon er igang. "Flush" buffer kommandoen blir sendt som en umiddelbar pakke.

Kontrollfunksjonen kjør utvidet diagnostikk fører til at innretningen utfører en diagnostiseirngfunksjoner og rapporterer resultatet av disse. Disse disgnostiserings-funksjonene kan være identisk til de som alltid kjøres ved oppstart, eller kan være utvidete eller spesielle tester. Denne kommandoen blir gjenkjent av alle klienter på en måte som er spesiell for den typen. Klienter som ikke implementerer utvidet diagnostiseringsfunksjoner rapporterer vellykket fullførelse av denne kommandoen. Denne kommandoen blir gjenkjent av alle klienter, blir avvist av alle servere, og blir bare akseptert når en sesjon er igang. Kommandoen kjør utvidet diagnostikk kan sendes enten i umiddelbar eller normal pakke. Den administrative informasjonsseksjonen i IONET-kommandoen kan inkludere informasjon omkring diagnostikk-parametre, og den administrative informasjonsseksjonen i IONET svarpakken kan inneholde informasjon vedrørende diagnosens resultater.

Kontrollfunksjonen rapporter ststus medfører at innretningen genererer en svarpakke som inneholder informasjon om ststusen til inn/ut-grensesnittet for innretningen. Denne kommandoen gjenkjennes av alle klienter på en måte som er spesifikk for den typen. Kommandoen blir avvist hvis ingen sesjon er i gang. Kommandoen kan sendes enten som en normal eller som en umiddelbar pakke. Minimums-responsen i IONET svarpakken består av standardisert grensesnittkontroll og status diskutert nedenfor i sammenheng med bytestrømsfunksjonene på sesjonsnivå.

Bytestrømsfunksjonene på sesjonsnivå omfatter "DATAI", for å overføre initielle eller mellomliggende datapakker: "DATAF" for å overføre avslutnings- eller enkle datapakker; "IDLE" for å plassere mottaker tilstandsmaskinen i en stopptilstand; og "NOP" for beskjeder som holder liv i kommunikasjonen. Bruken av disse funksjonene blir diskutert nedenfor i samband med transport kontrollens tilstandsmaskiner.

Den administrative informasjonsdelen av dataområdet av "DATAF og "DATAF" IONET-pakker er nyttet for å standardisere grensesnittskontroll og status fasilitet. Fordelen med standardisert grensesnittskontroll og status fasilitet er at det gir midler for direkte tilgang på innretningskontroll og statusinformasjon på en måte som er uavhengig av det fysiske grensesnittet til typen av inn/ut-innretning. At inn/ut-innretningen er typeuavhengig tillater en enkel implementering av lavnivå programvare ved en server for å kommunisere med og styre så å si alle typer av inn/ut-innretninger.

Det administrative dataområdet av "DATAI" og "DATAF" IONET-pakkene brukes for å holde et inndata status ord ("Input Status Word", "ISW") som rapporterer status hos de inngående eksterne grensesnitts kontrollsignaler og gir en indikasjon på alminnelig strøm av/på og alminnelig klar/ikke-klar status; et status maske ord ("Status Mask Word", "SMW") som velger hvilke inngangsstatusendringer som er av interesse for sesjonspartneren og bør medføre rapportering i den administrative data delen; og et utdata kontrollore ("Output Control Word","OCW") som spesifiserer oppsettet av signal for eksterne grensesnitts utgangskontroll.

Alle "DATAI"- og DATAF"-pakker som nyttes for dataoverføring nyttes som føl-ger: Hvis den administrative datadelen er null, er det ingen endring i grensesnitt kontroll eller status; hvis det er nøyaktig to bytes av administrativ data er disse "ISW", hvis det er nøyaktig fire bytes, er disse "ISW" etterfulgt av "SMW", hvis det er nøy-aktig seks bytes med administrative data, er disse respektive "ISW", "SMW", og "OCW", og hvis det er flere enn seks bitgtupper, er de første seks "ISW", "SMW", og "OCW", mens øvrige bytes er typespesifikk. For å gi muligheten til rapportering og setting av informasjon i senere ord uten å på virke informasjonen i fotutgående ord, er den mest signifikante bit av hver "ISW", "SMW" og "OCW" en validieringsbit. Et ord med validieringsbit satt til null, blir ignorert. For kommunikasjon fra klienter til servere, rapporterer "ISW" ekstern grensesnittskontroll sin inndata status, "SMW" rapporterer det nåværende maskesetting, og "ISW" rapporterer ekstern grensesnittskontroll sin utdata status. For kommunikasjon fra servere til klienter er "ISW" ikke i bruk, "SMW" brukes for å sette maskeverdien, og "ISW" setter ut-ganger for den eksterne grensesnittskontroll. For kommunikasjon fra servere til servere er "ISW", "SMW" og "OCW" generelt ikke ibruk, og for kommunikasjon fra klienter til klienter er disse ordene generelt ikke i bruk.

En strategi dom er tilgjengelig fra foreliggende oppfinnelse for å oppnå sikkerhet på sesjonsnivåfor databeskjed kommunikasjon er basert på bruken av "SID" for å forhindre at at en tredje innretning blander seg inn i kommunikasjonen mellom et par innretninger som deltar i en IONET-sesjon. Når en sesjon er i gang, er data- og kontroll-pakker bare akseptert hvis deres "SID" stemmer med den "SID" på den noden som sendte den opprinnelige oppkoplingsfunksjonspakken, eller som sendte svaret til den opprinnelige oppkoplingspakken. I tillegg til å være veldig enkel og effektiv å implementere og ikke kreve noe ekstra maskinvare, gir denne sikkerhets-teknikken en barriere mot uautorisert kommunikasjon fra de andre nodene. Dette oppstår på grunn av at ARCNET lenkenivå maskinvare hindrer overføringen av en "SID" annen enn dens etablerte "SID".

Sesjoner kan etableres og kontrolleres ved bruken av passord og konfigurasjons-låser. Et passord er spesiell informasjon etablert i lageret hos en innretning. For å kunne etablere en sesjon, må oppkoplingskommando-pakken stamme fra en innretning som har en "SID" som korresponderer med passordet, eller er innen en gruppe av "SID" definert av passordet. Alle klinter vedlikeholder spesielle innretningspmetre i ikke-flyktig lager. Innholdet av dette ikke-flyktige lageret kan aksesseres og opp-dateres av IONET kontrollfunksjoner hvis ikke en konfigurasjon slås er satt av en annen IONET-kontrollfunksjon. Når konfigurasjonslåsen først er satt, er det ikke mulig å gjøre noen endringer i det ikke-flyktige lageret før konfigurasjonslåsen er fjernet ved menneskelig inngrep på innretningen, f.eks. operere en bryter. Setting av konfigurasjonslåsen tillater innretninggens konfigurasjon fra å bli modifisert uten autorisasjon.

Klienter kan konfigureres for fjern sesjonsinitiering, i et slik tilfelle må en server initiere sesjonen. Ved å beskytte filene med konfigurasjonsinformasjonen ved de relevate serverene, kan brukere forhindres fra å endre lokasjonen og/eller karakteristikken på den prosessen som vil initiere sesjonen. Klienter kan konfigureres for forhåndsbestemt sesjonsinitiering, i det tilfellet er sesjonspartneren idintifisert og fast i det ikke-flyktige lageret hos klienten. Konfigursjonslåsen blir satt for å forhindre at brukeren og applikasjonsprogramvaren ikke endrer sesjonsinitieringstypen og sesjonspartneren. Fordi klienter konfigurert for forhåndsbestemte sesjoner ikke aksepterer beskjeder eller sesjonspartner identifikasjon fra brukeren, gir forhåndsbestemte sesjoner muligheten til en direkte, dedikert forbindelse mellom en enkelt server og en enkelt klient på tross av den multikontekst- og multiplekset naturen hos kommuniksa-sjonsmediet. Denne formen for dedikert punkt-til-punkt kommunikasjonen på et multiplekset medium er ikke typisk tilgjengelig på konvensjonelle inn/ut-kanaler unn-tatt gjennom bruken av dedikert punkt-til punkt enkel kabel. Forespørsler om fjern sesjonsinitiering som mottas ved enhver innretning kan kreve et passord hvis ikke typen av sesjonsinitiering er er definert på forhånd, for derigjennom tillate innretninger å bli konfigurert for å hindre uautorisert tilgang. I tilfellet for distribuerte adaptere, kan det fjerne passordet ikke leses ut eller bli modifisert hvis konfigurasjonslåsen er satt.

Tilstandsmaskinen for tilstandskontroll opererer for å gi den funksjonaliteten som er nødvendig for å kommunisere over IONET kommunikasjonskanalen, og operere i respons til IONET protokollen sm beskrevet overfor. Kommunikasjonen er en tovegs logisk lenke, på sesjonsnivå, mellom par av kommuniserende innretninger. Hvert logisk ledd involverer to sendere og to mottakere, som alle er komtrollert av hver sin enkle tilstandsmaskin. Hver sesjon har en forekomst av både sender- og mottakertilstandsmaskin som opererer ved hver node som deltar i sesjonen.

Hensikten med tilstandsmaskinen er å synkroniserer leveransen av bytes, kvittere vellykkede mottak av pakker, detektere og retransmittere savnede eller tapte pakker, detektere og ignorere dupliserte pakker, gi periodiske "holde-liv-i"-pakker ved de perioder når ingen data overføres, gi flytkontroll for å hindre overføring av pakker som det ikke er tilgjengelig noe mottakerbuffer for, og unngår unødvendig flytkontroll aktiviteter ved å stoppe kommunikasjonen i perioder når det ikke er noe data å sende og/eller bufferplass for å motta data, for deretter å gjenoppstarte kommunikasjonen når disse betingelsene igjen er tilstede.

"TXSB" i IONET-overskrifta kommuniserer tilstanden hos den sender tilstandsmaskinen som sender pakken til den mottaker tilstandsmaskinen som skal motta pakken. "RXSB" kommuniserer tilstanden hos den mottaker tilstandsmaskinen ved den innretningen som sender denne pakken (ikke den mottaker tilstandsmaskinen som mottar pakken) til den sender tilstandsmaskinen ved den innretningen som er

mottaker av denne pakken (ikke den sender tilstandsmaskinen som sender denne pakken).

Kvittering for hver pakke foreligger som "RXSB" i den neste pakken sendt av den senderen ved den innretning som mottok den pakken som det kvitteres for. I perioder med bidireksjonell kommunikasjon vil denne påhengte kvitteringen ta vare på nettverkets båndbredde. I perioder med unidireksjonell kommunikasjon vil det ikke være noen pakker som gå i motsatt retning, likevel vil pakker som inneholder kvittering bli generert. Når enten sender tilstandsmaskinen eller mottaker tilstandsmaskinen har en statusendring å rapportere, blir en pakke sendt. Hvis en av tilstandsmaskinene ikke har noe å sende på det tidspunkt, rapporterer den ingen status ved hjelp av en "NOP"-kode i statusbyten.

Teller for maksimalt antall pakker blir etablert mellom sesjonspartnere på samme tid som selve sesjonen blir etablert. Disse tellerne, som ikke trenger å være de samme for de to kommunikasjonsretningene, spesifiserer maksimalt antall datapakker som senderen kan sende uten en kvittering fra mottakeren. (Kommandopakker blir alltid sendt en ad gangen med svar for hver kommando.) Senderen må bevare kopier av hele gruppen av datapakker helt til kvittering er mottatt for å holde muligheten for retransmisjon åpen. Hvis en feil i mottak eller synkronisering oppstår, vil denne statusen rapporteres med en gang. Umiddelbare datapakker og alle kommandopakker blir kvittert for ved mottak, uavhengig av senderpakketelleren. Pakker med normal prioritet kan utpekes til å generere positive kvitteringer. Mottakeren må ha tilstrekkelig antall buffere for å ta vare på det maksimale antall med ukvitterte pakker før det indikeres til senderen at den er klar for mottak.

Normal verdi for sendepakketeller er én pakke, som resulterer i positiv kvittering for hver pakke som sendes. Den høyeste tillatte pakketellerverdien er 15, og er begrenset til bruken av et tall på fire biter for å holde vedlike synkroniseringa av pak-keleveransene. Senderpakketelleren brukt av enhver innretning bør ikke overstige en verdi mindre enn antall pakker den assosierte mottakertilstandsmaskinen kan holde uten å måtte kople ut "RIM" mottakeren. Jo høyere senderpakketeller, dess mindre båndbredde på nettverket og mindre prosesseringstid nyttes for å sende kvitteringer, og mindre tid må gå mellom suksessive transmisjoner; men et større antall buffere må tilbys av sendertilstandsmaskinen for å behandle det mulige behovet for retransmisjon.

Operasjon for sender og mottakertilstandsmaskiner er forholdsvis enkel å implementere i enten maskinvare eller programvare. Programvareinnplementering er å fore-trekke på grunn av økonomien, og fordi maskinvareinnplementering vil resultere i en uakseptabel stor fysisk størrelse for det distribuerte adapteret, for de fleste applikasjoner. Fig. 13 og 14 viser den generelle tilstandsovergangen med hensyn på hvilke kriter-ier som flytter sender og mottakertilstandsmaskinene mellom deres tilstander. Kriter-iet som gjør at tilstandsmaskinen forblir i samme tilstand er karakterisert ved enten komplett bestemmelse basert på mottatt informasjon som vist i de følgende tilstands-endringstabeller i figurene 15, 16, 17 og 18 eller ved mottak av pakker som er utenfor protokollen og derfor ignorert og forlater maskinen i den samme status samme tilstand. Fig. 13 viser de fem grunntilstander for senderen: Sender aktiv ("Transmitter Active", "TA") Når sender har informasjon å sende og er i gang med å sende eller forsøker å sende; sender venter ("Transmitter Waiting", "TW") når senderen er i stand til å sende data når det gjelder flytkontrollen, men ikke har noe å sende, og derfor venter på de interne forhold innenfor dens node for å framskaffe mer data; sender stoppet ("Transmitter Stopped", "TS"), som viser at sendinga har blitt stoppet på grunn av transportnivå flytkontroll, det vil si en opptatt-indikasjon fra mottakertilstandsmaskinen på det motsatte enden av sesjonen; umiddelbar modus sender aktiv ("Immediate Mode Transmitter Activ", "ITA") endret fra en normal modus når det er en umiddelbar pakke som skal sendes; og umiddelbar modus sender stoppet ("Immediate Mode Transmitter Stopped", "ITS") som er ekvivalent med "TS" men oppstår på grunn av transport flytkontroll når den er i umiddelbar modus. Tilbakefall fra umiddelbar modus til normal modus er implisitt så snart som at alle de umiddelbare pakker har blitt sendt. Status som indikerer ut av sesjon er strengt tatt ikke en status, men heller en tilstand hvor tilstandsmaskinen ikke opererer på grunn av at ingen sesjon er igang. Ut av sesjonstilstanden er entret etter tilbakestilling av kanalen eller noden, såvel som et resultat av avslutning av sesjonen enten gjennom nedkopling kontrollfunksjonen eller et tidsutløp som terminerer sesjonen.

Når en sesjon etableres, går sendertilstandsmaskinen inn i "TS" ("Sender Stopped") tilstand på grunn av det faktum at før det mottakende innretningen har indikert at den er klar til å ta imot data, må senderen anta at innretningen kan være opptatt. På samme måte, innen enhver sesjon, er den første ting som kommuniserer i sesjonen en klarindikasjon fra mottaker sendt til senderen om å ta senderen ut av "TS" tilstanden. De gjenværende tilstander og årsaker som fører til bevegelse mellom tilstander vil forstås på bakgrunn av diagrammet i fig. 13.

Fig. 14 viser de fem grunnleggende mottakertilstander: mottaker aktiv ("Receiver Active", "RA") når mottakeren mottar informasjon; mottaker venter ("Receiver Waiting", "RW") når mottakeren er i stand til å motta data når det gjelder flytkontroll men ikke egentlig mottar data og derfor venter til data skal bli tilgjengelig; mottaker stoppet ("Receiver Stopped", "RS") indikerer at sendinga av data har blitt stoppet som et resultat av en indikasjon fra sendertilstandsmaskinen på det motsatte ende av sesjonen om at ingen flere data trenger å sendes denne gangen; umiddelbar modus mottaker aktiv ("Immediate Mode Receiver Activ", "IRA") entret fra normal modus når det er umiddelbare pakker som skal mottas; og umiddelbar modus mottaker venter ("Immediate Mode Receiver Waiting", "IRW"), som er ekvivalent med "RW", men oppstår på grunn av tranportnivå flytkontroll når en er i umiddelbar modus. Tilbakefall fra umiddelbar modus eller normal modus er implisitt så snart som hver umiddelbare pakke har blitt kvittert. Statusen indikert som ut av sesjon er strengt talt ikke en status, men heller en tilstand hvor tilstandsmaskinen ikke opererer på grunn av at ingen sesjon er i gang. Ut av sesjonstilstanden er etter en tilbakestilling av IONET-kanalen eller noden, såvel som et resultat av slutten på sesjonen enten gjennom en nedkoplingskontrollfunksjon eller tidsforløp som terminerer sesjonen.

Når det gjelder diagrammet for mottakertilstandsmaskinen, vist i fig. 14, er tilstander og tall og retning og de endringsvilkårne som legger tilstandene, identisk med diagrammet for sendertilstandsmaskinen i fig. 13, bortsett fra at endring fra ut av sesjonsstilstand går til "RW" (mottaker venter) tilstand heller enn "RS" (mottaker stoppet) tilstand ved etablering av sesjonen. Bemerk sammenparinga av tilstander vist i figurene 13 og 14. Ordinert er "TA" og "RA" det par som tar seg av aktiv kommunikasjon. Hvis senderen ikke har noe mer å sende, indikerer den passiv og går til "TW" tilstand. Passivbeskjeden fra senderen plasserer mottakeren i "RS" tilstand. Mottakeren vil flyttes fra "RS" tilstand ved at senderen igjen blir aktiv, hvilket er en endring fra "TW" tilbake til "TA". Hvis mottakeren bruker opp alle buffere som skal holde innkomne data, indikerer den en ikke klar tilstand, ved at den går fra "RA" til "RW". Dette flytter senderen inn i "TS" tilstanden. Det som flytter senderen ut av "TS" tilstanden er en klarindikasjon fra mottakeren, som oppstår når mottakeren flyttes fra "RW" tilbake til "RA" når ledige buffere igjen er tilgjengelige. Når aktiv kommunikasjon foregår, er både senderen og mottakeren i sine aktive tilstander, "TA" og "RA". Hvis sendinga har blitt suspendert på grunn av at senderen ikke har noe mere å sende, er senderen i "TW" og mottakeren i "RS", men hvis sendinga har blitt stoppet på grunn av at mottakeren ikke har noe ledig plass for mer data, er mottakeren i "RW" og senderen i "TS".

Mer spesifikke detaljer når det gjelder operasjonen av sender og mottakertilstandsmaskinene er diskutert nedenfor i forbindelse med figurene 15, 16, 17 og 18.

Sendertilstandsmaskinen tar seg av alle utgående pakker for en gitt innretning, gir sendertilstandsbyte "TXSB" for alle pakker som den behandler, genererer sekvensnummer for utgående datapakker, sammenholder kvitteringer med pakker som har blitt sendt, retransmitterer ukvitterte pakker etter at et tidsforløp har gått ut, genererer holde-liv-i-pakker ved forhåndsbestemte tidsintervall i perioder når ingen utgående data er tilgjengelig, og bryter forbindelsen hvis mer enn en større andre forhåndsbestemte tidsperiode går ut uten et tilstandsvar fra den korresponderende mottakertilstandsmaskinen.

Sendertilstander for normal modus er vist i fig. 15. Tilstandene er sender aktiv ("Transmitter Activ", "TA") entret når det er utgående data å sende og når senderen venter på kvittering for avsendte pakker; sender venter ("Transmitter Waiting", "TW"), entret når den siste sendte pakke har blitt kvittert og det ikke er noe mer utgående data tilgjengelig; og sender stoppet ("Transmitter Stopped", "TS"), entret når mottaker har stoppet kommunikasjonen på grunn av at ingen buffere er tilgjengelig hos mottakeren. Avsending av normale pakker og av umiddelbare pakker er behandlet som uavhengige aktiviteter. Det finnes en halv-avhengig sendetilstands-maskin for umiddelbare pakker, vist i fig. 16, som nytter "ITA" og "ITS" sendertilstander. Etter tilbakestilling, såvel som når ingen umiddelbare pakker venter eller avventer ei kvittering, er sendertilstandsmaskinen i normal modus og bruker "TA", "TW" og "TS".

Når en umiddelbar pakke skal sendes mens sendertilstandsmaskinen er i normal modus, entres umiddelbar modus i en "ITA" tilstand og sender pakken. Med en gang den umiddelbare tilstanden er entret vil sendertilstandsmaskinen forbli i umiddelbar modus helt til alle ventende umiddelbare pakker har blitt sendt og kvittert for. Ved dette tidspunkt returnerer sendertidsmaskinen til normal modus i den tilstand som var aktiv i det tidspunkt første umiddelbare pakke ble presentert.

På grunn av den samtidige operasjon av sendertilstandsmaskinen og mottaker tilstandsmaskinen ved de to endene av hver retning av hver sesjon, kan pakker som relaterer til normal prioritet mottas ved en sendertilstandsmaskin mens den behandler en umiddelbar pakke. Disse mottak behandles på bakgrunn av status av normal modus sender, selv om ingen annen normal modus operasjon foregår før den umiddelbare modus prosesseringa er avsluttet.

Sendertilstandsmaskinen forventer positiv kvittering for hver umiddelbar pakke uavhengig av verdien spesifisert i senderpakketelleren.

En hel rekke heltallsverdier blir vedlikeholdt av sendertilstandsmaskinen for å følge beskjedsekvenser og detektere manglende og/eller dupliserte pakker. Disse inkluderer

n, som representerer foreliggende sekvensnummer brukt for transmisjon av pakker med normal prioritet;

m, som representerer det høyeste (normal prioritet) beskjedsekvenstall som den korresponderende mottakertilstandsmaskinen har kvittert for velykket mottak av;

p, som representerer det foreliggende sekvenstall brukt for overføring av umiddelbare pakker;

t, som representerer sendepakketelleren som brukes for denne retningen av den aktive sesjonen; og

x som representerer en verdi i området 0 til 15.

Alle størrelsesordenforhold mellom disse talla er implementert slik at overgang fra 15 til 0 skjer ved en økning i størrelsesorden. Dette er utvetydig fordi t må være mindre enn 16.

Sendertilstandsmaskinen indikerer sine tilstands-endringer ved hjelp av operasjons-kode og sekvensnummer i sendertilstandsbyten ("TXSB") hos hver sendte pakke. Tillatte operasjoner innkluderer

"DATAIn", som indikerer at denne pakken innholder bytestrømmer eller også administrative data og at denne pakken er en første eller mellompakke i en gruppe av to eller flere pakker som sendes uten positiv kvittering;

"DATAFn", som indikerer at denne pakken inneholder bytestrøm og/eller administrative data og at denne pakken er den siste (eler eneste) pakken i en gruppe, og at positiv kvittering kreves;

"IDLEn", som indikerer at ingen flere data på det nåværende tidspunkt (foreløbig) er tilgjengelig etter datapakke n-1;

"NOPx", brukt for holde-liv-i beksjeder (sekvensnummer er ignorert);

"CONTROL COMAND", brukt for funksjoner som for eksempel oppkopling, nedkopling, rapporter innretningsparametre, og så videre (sekvensnummer ikke brukt).

"COMMAND REPLY", brukt for å sende avslutningskoder og svardata som respons til "CONTROL COMMAND" (sekvensnummer ikke brukt).

De hendelser som kan føre til tilstandsendringer i sendertilstandsmaskinen omfatter

"READYn+1", som viser mottak av en pakke til hvilken mottaker tilstandsbyte inneholder kvittering type "READYn + 1", som indikerer at mottakeren har vellykket mottatt alle pakker sendt til og med "DATAFn", og at mottakeren har tilstrekkelige buffere tilgjengelig for en gruppe av pakker tilsvarende lengden av den aktive senderpakkertelleren;

"BUSYn+1", som angir mottak av en pakke til hvilken mottakerstatustilstandsbyte inneholder kvittering type "BUSYn+1", som indikerer at mottakeren har på en velykket måte mottatt alle pakker sendt til og med "DATAFn", men at mottakeren på det nåværende tidspunkt ikke har flere buffere tilgjengelig (eller et utilstrekklig antall av buffere for å motta en gruppe av pakker tilsvarende lengden av den aktive senderpakketelleren);

"READYm+1", som angir mottak av en pakke til hvilken mottakertilstandsbyt inneholder kvittering type "READYm + 1", som indikerer at mottakertilstands-maskinen har velykket mottatt alle pakker som er sendt til og med "DATAFm", har ikke velykket mottatt pakker sendt med sekvensnummer m+1, og at et nytt forsøk

med pakke "m" (og etterfølgende) avsending er nødvendig;

"Ingenting sendt, data tilgjengelig", som indikerer at en eler flere nye utgående pakker har blitt presentert for avsending ved det tidspunkt at ingen datapakker har blitt sendt siden disse "READYn+1", "READYm+1" eller "Tl" hendelse;

"DATAIn avsendt, mer data tilgjengelig", som indikerer at en eler flere utgående pakker i tillegg venter på sending ved det tidspunkt når minst en "DATAIn"-pakke har blitt avsendt siden siste "READYn + 1", "READYm + 1", eller "Tl" hendelse;

"Tl", som viser at tidsintervall relatert til nye forsøk og holde-liv-i pakker, dette tidsintervall er tilbakestilt hver gang en pakke sendes til sesjonspartneren; og

"T2", som viser at utgangen av tidsintervall relatert til tap av kommunikasjon eller protokollødeleggelse, denne tidsperioden er tilbakestilt hver gang en gyldig pakke blir mottatt fra sesjonspartneren.

På grunn av de forskjellige situasjoner, inkludert et foregående forsøk på å sende en pakke til en innretning der dennes "RIM"-mottaker er forhindret, kan det være tilfeller der det er behov for en sendertilstandsmaskin som sender en pakke når dens "RIM"-sender er opptatt. Når dette skjer vil sendertilstandsmaskinen temporært slutte å behandle alle hendelser vist i dens tilstandsendringstabell, med unntak av hendelsen som angår utgang av "T2" intervallet. Etter at en sender har blitt tilgjengelig, og er igjen gjort klar for å sende den ventende transmisjonen, vil enhver hendelse som har skjedd under perioden før senderen var opptatt bli behandlet. Behandling av mottatte "NOPx" pakker (for å tilbakestille "T2") er også utsatt under perioder når senderen er opptatt. Operasjon av sendertilstandsmaskinen i normal modus er karakterisert ved

tabellen vist i fig. 15. For hver boks i tabellen, indikerer navn med store bokstaver

sending av pakker med den indikerte funksjon i senderens statusbyte, navn med små boksataver indikerer interne operasjoner innen sendertilstandsmaskinen, og navn som begynner med en høyrepil indikerer den status som entres ved avslutning av aktiviteten i den boksen.

Andre operasjonelle karakteristika av sendertilstandsmaskinen er som følger. Hvis flere enn en hendelse skjer samtidig, vil hendelsen vist i kolonnen lengst til venstre i

tabellen bli behandlet først. Andre hendelser blir kun behandlet hvis de fremdeles er sann etter at den initielle hendelsen er behandlet. "Tl" tidsintervall varierer med sendertilstanden som vist, "T2" tidsintervall er alltid en fast verdi større enn "Tl".

Mottak av enhver mottakertilstandsbeskjed av "NOPx" (uavhengig av sekvensnummer) gjør at T2 intervallet blir tilbakestilt, men er ellers ignorert av mottakertilstandsmaskinen. Avsending av en "CONTROL COMMAND" eller et "CONTROL REPLY" kan foregå med "DATAFn" er tilstede. Ingen videre overføring skjer etter at en "CONTROL COMMAND" er avsendt, før det korresponderende "CONTROL REPLY" er mottatt. Hvis Tl tidsintervall utgår mens en venter på dette "CONTROL REPLY", vil "CONTROL COMMAND" bli retransmittert. Ingen kvittering er ventet eller kreves, for hvert "CONTROL REPLY". Hvis T2 tidsintervall utgår uten at et "CONTROL REPLY" er mottatt, vil "CONTROL COMMAND "-aktiviteten (og sesjonen, hvis noen) bli terminert. Alle pakker mottatt fra sesjonspartneren med mottakertilstandsverdier andre enn de som er vist av de hendelser definert i tilstandsendringstabellen er ignorert av sendertilstandsmaskinen uten å tilbakstille "T2" intervallet. Dette resulterer i en tidsbasert sesjonsavslutning på grunn av protokoll-ødeleggelse. Det er også feiltilstander vist i tilstandsendringstabellen som spesifiserer at T2 tidsintervallet ikke skal tilbakestilles. Ved etablering av en sesjon, eller ved resynkronisering, vil sendertilstandsmaskinen entre tilstanden TS med n:= m:= -1.

Operasjon av sendertilstandsmaskinen i umiddelbar modus er karakterisert ved

tabellen vist i fig. 16. For hver boks i tabellen indikerer navn med store bokstaver avsending av pakker med den indikerte funksjon i senderstatusgruppen, navn med små bokstaver indikerer interne operasjoner innen sendertilstandsmaskinen, navn som starter med en høyre pil indikerer tilstanden som entres når aktiviteten i boksen avsluttes, og betegnelsen "Tx" refererer seg til normal modal tilstand ("TA", "TW", eller "TS") som er korrekt å entre ved avslutning av en umiddelbar modus operasjon.

Andre operasjonelle karakteristika av sendertilstandsmaskinen i umiddelbar modus er som følger. "Tl" tidsintervall varierer med sendertstatus som vist, "T2" tidsintervall er alltid en fast verdi større enn "Tl". Disse "Tl" og "T2" tidsintervall er de samme som brukes ved normal modus sendertilstandsmaskin. Mottak av enhver mottakertilstandsbeskjed av "NOPx" (uavhengig av sekvensnummer) gjør at "T2" tidsintervall blir nullstilt, men blir ellers ignorert av sendetilstandsmaskinen. Avsending av en "CONTROL COMMAND" eller et "CONTROL REPLY" kan foregå når "DATAFp" foreligger. Ingen videre transmisjon foregår etter at "CONTROL COMMAND" er sendt, før de korresponderende "CONTROL REPLY" blir mottatt. Hvis "Tl" tidsintervall utgår mens en venter på dette "CONTROL REPLY" vil "CONTROL COMMAND" bli retransmittert. Ingen kvittering er ventet, eller kreves, for hvert "CONTROL REPLY". Hvis "T2" tidsintervall går ut uten at et "CONTROL REPLY" er mottatt, vil "CONTROL COMMAND "-aktiviteten, sesjonen, hvis noen, bli terminert. Alle pakker som mottas fra sesjonspartneren med mottaker-stauts-verdier andre enn de som er beskrevet av hendelsene definert i tilstandsendringstabellen er ignorert av sendertilstandsmaskinen uten å nullstille "T2" tidsintervall. Dette resulterer i en tidsbasert sesjonsavslutning på grunn av protokollødeleggelse. Det er også feiltilstander vist på tilstandsendringstabellen som spesifiserer at "T2" tidsintervall ikke skal nullstilles. Ved etablering av en sesjon, eller ved resynkronisering blir verdien av p initiert til null. Ved entring til umiddelabar modus, vil sendertilstandsmaskinen sende en "DATAFp" pakke og gå inn i "ITA" tilstand. Verdien som benyttes for denne "DATAFp" pakke er uforandret fra den forrige utgang fra umiddelbar modus (eller resynkronisering).

Mottakertilstandsmaskinen behandler alle innkomne pakker for en gitt innretning, gir mottakertilstandsvittgruppen "RXSB" for inkorporering i alle utgående pakker fra denne innretningen; genererer sekvensnummer for utgående kvitteringer; retransmitterer indikeringer om at ledige buffere er tilgjengelig hvis ingen nye pakker er mottatt innen et tidsintervall; genererer holde-liv-i pakker ved forhåndsbestemte tidsintervall når ingen ledige buffere er tilgjengelig; og bryter forbindelsen hvis mer enn en større andre forhåndsbestemt tidsperiode har utløpt uten at et statussvar fra korresponderende sendertilstandsmaskin er mottatt.

Mottakertilstander for normal modus er vist i fig. 17. Mottakertilstandene er mottaker aktiv ("Receiver Active", "RA") entret når det er en eller flere mottakerbuffere tilgjengelig; mottaker venter ("Receiver Waiting", "RW"), entret når ingen mottakerbuffere er tilgjengelig; og mottaker stoppet ("Receiver Stopped", "RS"), entret når senderen har stoppet kommunikasjonen fordi den ikke har noe utgående data å sende.

Mottak av normale pakker og av umiddelbare pakker er behandlet som uavhengige aktiviteter. Det finnes en halv-avhengig mottakertilstandsmaskin for umiddelbare pakker, som nytter "IRA" og "IRW" mottakertilstander. Etter tilbakestilling, såvel som når ingen umiddelbare pakker har blitt mottatt og ennå ikke kvittert, er

mottakertilstands-maskinen i normal modus og bruker "RA", "RW" og "RS".

Når en umiddelbar pakke mottas mens mottakertilstandsmaskinen er i normal modus, entres umiddelbar modus i en "IRA" tilstand og kvitterer for pakken. Med en gang den umiddelbare tilstanden er entret vil mottakertilstandsmaskinen forbli i umiddelbar modus (status "IRA" og "IRW") helt til de mottatte umiddelbare pakkene har blitt kvittert for. Ved dette tidspunkt returnerer mottakertidsmaskinen til normal modus i den tilstand som var aktiv i det tidspunkt første umiddelbare pakke ble mottatt.

På grunn av den samtidige operasjon av sendertilstandsmaskinen og mottakertilstandsmaskinen ved de to endene av hver retning av hver sesjon, kan pakker som relaterer til normal prioritet mottas ved en mottakertilstandsmaskin mens den behandler en umiddelbar pakke. Disse mottak behandles på bakgrunn av status av normal modus mottaker, selv om ingen annen normal modus operasjon foregår før den umiddelbare modus prosesseringa er avsluttet. Dette medfører at det må være minst et (generelt akkurat et) mottakerbuffer tilgjengelig når en mottaker i normal modus entrer "RW" tilstand.

Mottakertilstandsmaskinen genererer positiv kvittering for hver umiddelbar pakke uavhengig av verdien spesifisert i mottakerpakketelleren.

En hel rekke heltallsverdier blir vedlikeholdt av mottakertilstandsmaskinen for å følge beskjedsekvenser og detektere manglende og/eller dupliserte pakker. Disse inkluderer

n, som representerer foreliggende sekvensnummer brukt for mottak av pakker med normal prioritet;

m, som representerer et sekvensnummer, forbundet med en mottatt pakke av normal prioritet, som kan være før n i sekvens, men som er innen området for den aktive pakke telleren. Når t=l er m=(n-l), når t er større enn 1 er (n-1) mindre enn m er mindre enn eller lik (n-1);

p, som representerer det foreliggende sekvenstall brukt for mottak av umiddelbare pakker;

t, som representerer sendepakketelleren som brukes for denne retningen av den aktive sesjonen; og

x som representerer en verdi i området 0 til 15.

Alle størrelsesordenforhold mellom disse talla er implementert slik at overgang fra 15 til 0 skjer ved en økning i størrelsesorden. Dette er utvetydig fordi t må være mindre enn 16.

Mottakertilstandsmaskinen indikerer sine tilstandsendringer ved hjelp av kvitteringskode og sekvensnummer i mottakertilstandsbytenhos hver pakke den sender. Tillatte kvitteringer inkluderer

"READYn", som viser at mottakeren har vellykket mottatt alle pakker sendt til og med "n-1", og at mottakeren er i

stand til å motta minst antall pakker tillatt av senderpakketelleren;

"BUSYn", som angir at mottakeren har på en velykket måte mottatt alle pakker sendt til og med "n-1", men på det nåværende tidspunkt har et utilstrekklig antall av buffere for å motta en gruppe av pakker tilsvarende lengden av den aktive mottakerpakketelleren; og

"NOPx", brukt for holde-liv-i beksjeder (sekvensnummer er ignorert); "DATAFn", som indikerer mottak av en pakke der senderstatus byten inneholder funksjonstype "DATAFn", som indikerer mottak av den neste ventede sekvens-verdien av den siste (eller eneste) pakken i en gruppe som krever positiv kvittering;

"IDLEn" som indikerer mottak av en pakke der senderstatus byten inneholder funksjonstype "IDLEn", som indikerer at senderen på det nåværende tidspunkt ikke har mer data å sende;

"DATAFm", som indikerer mottak av en pakke der senderstatus byten inneholder funksjonstype "DATAFm", som indikerer at sendertilstandsmaskinen ikke vellykket har mottatt siste kvittering til en datapakke og at et nytt forsøk på den overføringen (og påfølgende overføringer) er i gang; (Når t=l, m=(n-l), er DATAFm lik DATAFn.);

"DATAIn", som indikerer mottak av en pakke der senderstatus byten inneholder funksjonstype "DATAIn", som indikerer mottak av neste ventede sekvensverdi av en initiell eller mellomliggende datapakke i en gruppe av datapakker der kvittering vil genereres etter at alle pakkene er mottatt (noe som blir indikert ved mottak av en pakke av funksjonstype "DATAFn"); hvis antall "DATAIn"-hendelser siden siste "DATAFn"-hendelse overskrider den aktive sendepakketelleren minus 1, vil mottak av en "DATAIn"-pakke bli ignorert.

"t mottakerbuffere tilgjengelig", som indikerer at minst "t" ledige mottakerbuffere er blitt tilgjengelig etter en tilstand der mindre enn "t" ledige mottakerbuffere har vært ledige;

"T3", som viser at tidsintervall relatert til nye forsøk og holde-liv-i pakker, dette tidsintervall er tilbakestilt hver gang en pakke sendes til sesjonspartneren; og

"T2", som viser at utgangen av tidsintervall relatert til tap av kommunikasjon eller protokollødeleggelse, denne tidsperioden er tilbakestilt hver gang en gyldig pakke blir mottatt fra sesjonspartneren.

Operasjon av mottakertilstandsmaskinen i normal modus er karakterisert ved

tabellen vist i fig. 17. For hver boks i tabellen, indikerer navn med store bokstaver sending av pakker med den indikerte funksjon i mottakerens statusbyte, navn med små boksataver indikerer interne operasjoner innen mottakertilstandsmaskinen, og navn som begynner med en høyrepil indikerer den status som entres ved avslutning av aktiviteten i den boksen.

Andre operasjonelle karakteristika av mottakertilstandsmaskinen omfatter: Hvis flere enn en hendelse venter samtidig, vil hendelsen vist i kolonnen lengst til venstre i tabellen bli ferdigbehandlet først, før det tas noe hensyn til de lenger til høyre. Mottak av en "CONTROL COMMAND" eller et "CONTROL REPLY" gjør at mottakertilstandsmaskinen nullstiller T3 tidsintervall og sender pakken videre til de styringsfasiliteter som finnes i innretningen. Mottakertilstandsmaskinen gjør ikke noe annet, og vil ikke kvittere for "CONTROL COMMAND" eller hvert "CONTROL REPLY". T3 tidsintervallet varierer med tilstanden på mottakeren som vist, T2 tidsintervallet er alltid en fast tid. Mottak av enhver senderstatus beskjed "NOPx"

(uavhengig av sekvensnummer) gjør at T2 intervallrekneren blir nullstilt, men er ellers ignaorert av mottakertilstandsmaskinen. Alle mottatte pakker fra sesjonspartneren med senderstatus annen enn de som er dekket av de defifnerte hendelser, vil bli ignorert av mottakertilstandsmaskinen uten å nullstille T2. Dette vil innebære tidsbasert gjenoppretting ved protokollødeleggelser. Det finnes også feiltilstander vist i tilstandsendirngstabellen som spesifiserer at T2 telleren ikke skal nullstilles. Ved nullstilling eller etablering av en sesjon, går mottakertilstandsmaskinen inn i tilstand "RW" med n: =0.

Operasjon av mottakertilstandsmaskinen i umiddelbar modus er karakterisert ved

tabellen vist i fig. 18. For hver boks i tabellen indikerer navn med store bokstaver avsending av pakker med den indikerte funksjon i mottakerstatusgruppen, navn med små bokstaver indikerer interne operasjoner innen mottakertilstandsmaskinen, navn som starter med en høyre pil indikerer tilstanden som entres når aktiviteten i boksen avsluttes, og betegnelsen "Rx" refererer seg til normal modal tilstand ("RA", "RW", eller "RS") som er korrekt å entre ved avslutning av en umiddelbar modus operasjon.

Andre operasjonelle karakteristika av mottakertilstandsmaskinen i umiddelbar modus er som følger. Mottak av en "CONTROL COMMAND" eller en "CONTROL REPLY" pakke fører til at mottakertilstandsmaskinen nullstiller T2 tidsintervall og sender pakken videre til de prosesseringsfasiliteter som finnes for styringsfunksjoner i innretningen. Mottakertilstandsmaskinen gjør ikke noe annet, og sender ikke kvittering på "CONTROL COMMAND" eller hver "CONTROL REPLY". "T3" tidsintervall varierer med mottakertstatus som vist, "T2" tidsintervall er alltid en fast verdi. Disse "T3" og "T2" tidsintervall er de samme som brukes ved normal modus mottakertilstandsmaskin. Mottak av enhver sendertilstandsbeskjed av "NOPx"

(uavhengig av sekvensnummer) gjør at "T2" tidsintervall blir nullstilt, men blir ellers ignorert av sendetilstandsmaskinen. Alle mottatte pakker fra sesjonspartneren med senderstatus annen enn de som er dekket av de defifnerte hendelser, vil bli ignorert av mottakertilstandsmaskinen uten å nullstille T2. Dette vil innebære tidsbasert gjenoppretting ved protokollødeleggelser. Det finnes også feiltilstander vist i tilstandsendringstabellen som spesifiserer at T2 telleren ikke skal nullstilles. Ved etablering av en sesjon eller resynkronisering, blir mottakertilstandsmaskinen satt inaktiv med p initiert til 0. Ved inngang til umiddelbar modus, vil mottakertilstands-maskinen entre "IRA" status med verdien på "P" uforandret fra den foregående utgangen fra umiddelbar status (eller fra resynkronisering).

Fra den foregående beskrivelse av IONET-karakterkanalen i dens forskjellige aspekter, inkludert IONET-protokollen og funksjonaliteten til tilstandsmaskinen skulle betydningen av forbedringene tilgjengelig ved foreliggende oppfinnelse tre klart fram. Denne beskrivelsen skal likevel ikke tolkes som en begrensning av rekkevidden av oppfinnelsen ut over den lovmessige rekkevidden av de følgende patentkrav.

Claims (30)

1. Et system for å implementere en karakter-I/O-kanal (140; 140a, 140b) for å kommunisere bytestrømdata (266) og styringsadministrativ informasjon (264) i en enkelt IONET-netverksnivå-datapakkabeskjed (240) fra kilde- til destinasjonsinnretninger koplet til kanalen (140; 140a, 140b) ved et flertall av noder (174), hver kilde/destinasjonsinnretning omfatter et grensesnitt (182) som er koplet til et organ (176, 100; 176a, 100a, 100b) som er separat fra kilde/destinasjonsinnretningen, idet organet (176, 100; 176a, 100a, 100b) er en av enten en inn/ut-innretning (176;176A) som leder I/O-dataoverføringer, eller en datamaskin (100; 100a, 100b) omfattende et lager (104), en prosessor (102) og programkode for å drive datamaskinen (100; 100a, 100b), karakter I/O-kanalen (140; 140a, 140b) er anordnet for bruk i samband med et lokalt nettverk (LAN) omfattende et kommunikasjonsmedium (170; 170a, 170b) vanlig koplet til flertallet av noder (174), LAN-grensesnitt (178) ved hver node (174) for å styre tilgangen til mediet (170; 170a, 170b) og for å kommunisere LAN-pakker mellom gitte valgte kilde- og destinasjonsnoder (174), hver LAN-datapakke omfatter et LAN-datafelt og et LAN-overskriftfelt inneholdende karakterer som styrer grensesnittorganet (178) for å oppnå node til node-kommunikasjon i samband med en gitt LAN-kommunikasjonsprotokoll, karakterisert ved at karakter I/O-kanalen (140; 140a, 140b) omfatter i kombinasjon: brukspunkt ("point of use",POU) -organ (172) inkludert i kilde/destinasjonsinnretningen og koplet til LAN-grensesnittet (178) ved hver node (174), brukspunktorganet (172) er koplet til hver I/O-innretning (176;176A) inkludert en mikrodatamaskin (180) med lager og programkode for å drive mikrodatamaskinen (180), programkodene for prosessoren (102) og mikrodatamaskinen (180) definerer en gitt I/O-nett kommunikasjonsprotokoll for å kommunisere med kilde/destinasjonsinnretningene og deres tilkoplede grensesnitt (182) og organene (176, 100; 176a, 100a, 100b), idet I/O-nett kommunikasjonsprotokollen er separat fra LAN-kommunikasj onsprotokollen, brukspunktorganene (172) er anordnet for å sette inn karakterer i datafeltet i LAN-datapakkene for å danne I/O-nett-nettverksnivå-datapakkebeskjeder (240) som har et felt for I/O-nett-overskriftskarakterer (260) og et administrativt (264) og et byte- strømdatafelt (266), I/O-nett-overskirftskarakterene (260) inkluderer en funksjonskode (278) som spesifiserer en av et flertall av styringsfunksjoner, de administrative feltkarakterene omfatter en administrativ in formasjon skode (264) for bruk for å oppnå spesifiserte styringsfunksjoner som skal utføres ved en av kilde/destinasjonsinnretningene eller grensesnittet (182), bytestrøm datakarakterene 266 stammer fra et organ (176, 100; 176a, 100a, 100b) ved kildenoden (174), og brukspunktorganet (172) ved destinasjonsnoden (174) er anordnet for direkte å tolke funksjonskoden (278) og de administrative informasjonskodekarakterene (264) a) for å etablere en sesjon mellom kilde- og destinasjonsinnretning for å kommunisere I/O-nett-datapakkebeskjeder (240) mellom disse uten aksept og forstyrrelse fra andre I/O-nett-datapakkebeskjeder (240) gjennom sesjonens varighet, og b) å utføre en tilsvarende styringsfunksjon på en av destinasjonsinnretningene eller dens grensesnitt (182) under sesjonen, og c) samtidig å overføre bytestrømdatakarakterer (266) i umodifisert form direkte til organene (176,100; 176a, 100a, 100b) koplet til grensesnittet (182) til destinasjonsinnretningen.

2. System i samsvar med krav 1, karakterisert ved en styringsfunksjon som er en utkoplingsstyrings-funksjon som avslutter en etablert sesjon.

3. System i samsvar med krav 1, karakterisert ved at I/O-nett-overskriftskarakterene (260) omfatter en lengdekode (282,284) som spesifiserer en vilkårlig lengde for hver av administrative og bytestrøm datafeltene (264,266).

4. System i samsvar med krav 1, karakterisert ved at I/O-nett-overskirftkarakterene (260) omfatter en umiddelbar kode (268), og brukspunktorganet (270) ved destinasjonsinnretningen er anordnet for umiddelbart å utføre styringsfunksjonen spesifisert ved funksjonskoden (278) og den administrative informasjonskoden (264) ved mottak av I/O-nett beskjeden som inneholder den umiddelbare koden (268).

5. System i samsvar med krav 1, karakterisert ved at LAN-grensesnittet (278) er anordnet for å settes inn i kildenoden som identifiserer informasjon (246,248,272) i hver LAN-datapakke (240), og at mikrodatamaskinen (180) ved et brukspunktorgan (172) er anordnet for å hindre responsiv kommunikasjon av I/O-nettbeskjeder til en kilde/destinasjonsinnretning koplet ved en node (174) som har identifiseringsinformasjon (246,248) som ikke tilsvarer nodens identitetsinformasjon (246,248) ved kilde/destinasjonsinnretningene som sesjonen er etablert med.

6. System i samsvar med krav 1, karakterisert ved at LAN-grensesnittet (178) er anordnet for å sette inn en kildenode identifiseringsinformasjon (246,248,272) i hver LAN-datapakke (240) og at mikrodatamaskinen (180) ved et brukspunktorgan (172) omfatter passordinformasjon som identifiserer kilden (174) til hvert organ som er istand til å initiere sesjonen med kilde/destinasjonsinnretningen ved et brukspunktorgan (172), og at mikrodatamaskinen (170) ved et brukspunktorgan (172) er anordnet for å hindre kommunikasjon med I/O-nett-beskjeder untatt ved at kildeinformasjon (248) assosiert med mottatt I/O-nett-beskjed under en halv sesjon tilsvarer kilde-noden som identifiserer informasjon (248) ved kilde/destinasjonsinnretningen som tilførte passordinformasjon for å starte sesjonen.

7. System i samsvar med krav 6, karakterisert ved at mikrodatamaskinen (180) ved brukspunktorganet (172) videre omfatter et låseorgan for å hindre passordinformasjon fra å endres ved I/O-nettbeskjeder mottatt fra andre kilde/destinasjonsinnretninger.

8. System i samsvar med krav 1, karakterisert ved at en I/O-nettbeskjed som spesifiserer en kommando-funksjon etterfølges av kommunikasjon av en svar I/O-nettbeskjed som inneholder funksjonskode (278) og en administrativ informasjonskode (264) som spesifiserer om den forespurte kommandofunksjonen har blitt vellykket utført.

9. System i samsvar med krav 8, karakterisert ved at hver sesjon blir etablert ved kommunikasjon av en første I/O-nettbeskjed som inneholder en funksjonskode (278) og en administrativ informasjonskode (264) som spesifiserer en oppkoplingsstyringsfunksjon mellom to kilde/destinasjonsinnretninger og ved responsiv kommunikasjon av en spar I/O-nett beskjed som inneholder en funksjonskode (278) og en administrativ informasjonskode (264) som spesifiserer om sesjonen har blitt vellykket etablert.

10. System i samsvar med krav 9, karakterisert ved at hver sesjon inneholder to halvsesjoner, første I/O-nett beskjed etablerer en halvsesjon og svar-I/O-nettbeskjeden etablerer den andre halvsesjonen.

11. System i samsvar med krav 10, karakterisert ved at funksjonskoden (278) og den administrative informasjonskoden (264) av svar-I/O-nettbeskjeden blir direkte tolket ved en av mikrodatamaskinene (180) eller datamaskinen (100; 100a, 100b) ved en kilde/destinasjonsinnretning i den etablerte sesjonen for å forhindre kommunikasjon av ytterligere I/O-nettbeskjeder til andre kilde/destinasjonsinnretninger i den etablerte seksjonen til ytterligere I/O-nettbeskjeder kan mottas i lageret ved brukerpunktorganet (172) ved de andre kilde/destinasjonsinnretningene.

12. System i samsvar med krav 10, karakterisert ved at en I/O-nett datapakkebeskjed inneholder flere datapakker (240) som kommuniseres i en halvsesjon inkludert I/O-nett-overskriftkarakterer (260) anordnet for å spesifisere sekvensiell rekkefølge-informasjon (268) ved de flere datapakker (240), og hver halvsesjon svar I/O-nettbeskjed inkluderer I/O-nett-overskriftkarakterer (260) som spesifiserer kvitteringsinformasjon (270) som anvendes for å bestemme de av datapakkene (240) som ikke ble vellykket mottatt.

13. System i samsvar med krav 12, karakterisert ved at alle datapakker (240) som ikke ble vellykket mottatt retransmitteres i respons til svar I/O-nett-beskjed som inneholder kvitteringsinform-asjonen (270).

14. System i samsvar med krav 12, karakterisert ved at alle datapakker (240) som ikke ble vellykket mottatt retransmitteres i respons til utløp av en gitt tidsperiode under hvilken ingen svar I/O-nett-beskjed var mottatt.

15. System i samsvar med krav 8, karakterisert ved at svar I/O-nett-beskjeden inneholder karakterer (270, 278) i sin I/O-nett-overskrift (260), som spesifiseer svar som omfatter: vellykket avslutning av styringsfunksjonen, ikke-støtte av styringsfunksjonen ved destinasjonsinnretningen, avslag ved destinasjonsinnretningen av styringsfunksjonen pga. av status ved en mottaker ved destinasjonsinnretningen, avslag av styringsfunksjonen pga. at destinasjonsinnretningen ikke er i sesjon, avslag av styringsfunksjonen pga. at destinasjonsinnretningen er i sesjon med en annen kilde/destinasjonsinnretning, avslag av styringsfunksjonen pga. at konfigurasjonslåsen i samband med destinasjonsinnretningen er satt, og avslag av styringsfunksjonen pga. at det er en feil i styringskommandokarakter-informasjonen i styringskommando I/O-nettbeskjeden.

16. System i samsvar med krav 1, karakterisert ved at styringskommandoene for grensesnittet (182) omfatter: en kommando for å overføre datapakkebeskjeden, en kommando for å stoppe mottak av datapakkebeskjeder, og en kommando for å kommunisere hold-i-live beskjeder for å vedlikeholde sesjonen i fravær av kommuniserte datapakkebeskjeder.

17. System i samsvar med krav 8, karakterisert ved at styringskommandoene spesifiserer styringsfunksjoner omfattende: rapportere kilde/destinasjonsinnretningsparametre, som medfører generering av et styringssvar I/O-nettbeskjed som inneholder informasjon som angår type og gitte atributter ved innretningen (176,100; 176a, 100a, 100b) koplet til kilde/destinasjonsinnretningen, rapporter statistikk, som medfører generering av en styringssvar I/O-nettbeskjed som inneholder statistikk angående mediumkommunikasjon, rapporter grensesnittparametre, som medfører generering av styringssvar I/O-nett-beskjed som angår grensesnittkontroll og tilhørende modal status ved kilde/destinasjonsinnretningen, sette kilde/destinasjonsinnretningsparametre, som medfører at kilde/destinasjonsinnretningen kan lagre ny parameter-informasjon angående andre kilde/destinasjonsinnretninger i sesjonen, og sette grensesnittparametre, som medfører at destinasjonsinnretningen setter nye verdier for grensesnittstyring og tilhørende modal status.

18. System i samsvar med krav 8, karakterisert ved at styringsfunksjonene omfatter: "flush" buffere, som medfører at all tidligere informasjon kommunisert i I/O-nett-beskjeder til lagre ved mottakeren skal avvises, kjør utvidet diagnostikk, som medfører at kilde/destinasjonsinnretningen utfører diagnostiske funksjoner og rapporterer resultatene ved disse funksjonene, og rapporter status, som medfører at kilde/destinasjonsinnretningen genererer en styringssvar I/O-nett-beskjed som beskriver status til en grensesnittet (182) ved innretningen (176).

19. System i samsvar med krav 8, karakterisert ved at svar I/O-nett-beskjeden omfatter informasjon (268, 278) som spesifiserer: status ved kilde/destinasjonsgrensesnitt inngangssignal og en indikasjon av felles effekt på/av og felles klar/ikke-klar-status, valg av de inngangsendringer som resulterer i kommunikasjon styringssvar I/O-nettbeskjeder som inneholder statusinformasjon, og spesifikasjon av innstillinger ved grensesnitt utgangsstyringssignalene.

20. Framgangsmåte for karakterkommunikasjon i en karakter I/O-kanal (140; 140a, 140b) for kommunisering av byte-strømdata (266) og styringsadministrativ informasjon (264) i enkelte I/O-nett-datapakke beskjeder (240) på nettverksnivå fra kilde- til destinasjonsinnretning tilkoplet kanalen (140; 140a, 140b) ved et flertall av noder (174) ved kommunisering av LAN datapakker mellom kilde- og destinasjonsnoder i samsvar med LAN kommunikasjonsprotokollen, hver kilde/destinasjonsinnretning omfatter et grensesnitt (182) som er koplet til et organ (176, 100, 176a, 100a, 100b) som er separat fra kilde/destinasjonsinnretningen, organet (176,100; 176a, 100a, 100b) er en av enten en I/O-innretning (176,176A) som fører I/O-dataoverføringer eller en datamaskin (100; 100a, 100b) inkludert et lager (104) og en prosessor (102) og programkode for drift av datamaskinen (100; 100a, 100b),og framgangsmåten er beregnet for bruk med et lokalt nettverk (LAN) omfattende et kommunikasjonsmedium (170; 170a, 170b) vanligvis koplet til flertallet av noder (174), LAN-grensesnitt (178) ved hver node (174) for å styre tilgang til mediet (170; 170a, 170b) og kommunisere LAN-pakker mellom gitte valgte kilde- og destinasjonsnoder (174), hver LAN-datapakke omfatter et LAN-datafelt og et felt for LAN-overskriftkarakterer inneholdende karakterer som styrer grensesnittet (178) for å oppnå nodekommunikasjon i samsvar med en gitt LAN-kommunikasjonsprotokoll, karakterisert ved å omfatte følgende trinn: inkludere et brukspunkt (POU) -organ (172) i kilde/destinasjonsinnretningen og kople brukspunktorganet (172) til LAN grensesnittet (178) ved hver node (174), inkludere et mikrodatamaskin (180) omfattende et lager og en programkode for å operere mikrodatamaskinene (180) i hvert brukspunktorgan (172), implementere en IONET-kommunikasjonsprotokoll separat fra LAN-kommunikasjonsprotokollen i programkoden for hvert datamaskin (100; 100a, 100b) og mikrodatamaskin (180) og dermed: danne IONET-nettverksnivå-datapakkebeskjeder (240) i samsvar med IONET-kommunikasjonsprotokollen ved å sette inn karakterer i LAN-datafeltet i hver LAN-datapakke kommunisert mellom nodene (134), danne et IONET-overskriftfelt (160) og et administrativt felt (264) og et byte-strøm-datafelt (266) i hver IONET-datapakkebeskjed (240) ved å sette inn karakterer, IONET-overskriftkarakterene (260) inkludert en funksjonskode (278) som spesifiserer en av et flertall av styringsfunksjoner, de administrative feltkarakterene omfatter en administrativ informasjonskode (264) for bruk for å oppnå spesifisert styringsfunksjon som skal utføres ved den ene av kilde/destinasjonsinnretningene eller dens grensesnitt (182), bytestrøm datakarakterer (266) har opprinnelse fra en innretning (176,100; 176a, 100a, 100b) ved kildenoden (174), og direkte tolke funksjonskoden (278) og administrative informasjonskodekarakterer (264) ved destinasjonsnoden (174) i samband med IONET-kommunikasjonsprotokoll, og dermed a) etablere en sesjon mellom kilde- og destinasjonsinnretninger for kommunisere IONET-datapakkebeskjeder (240) mellom disse uten aksept av et grensesnitt fra andre IONET-datapakkebeskjeder (240) gjennom sesjonen, og b) utføre en tilsvarende styringsfunksjon på en av destinasjonsinnretningene eller dens grensesnitt (182) under sesjon, mens c) samtidig overføre bytestrømdatakarakterer (266) i umodifisert form direkte til innretningen (176,100; 176a, 100a, 100b) koplet til grensesnittet (182) ved destinasjonsinnretningen.

21. Framgangsmåte i samsvar med krav 20, karakterisert ved videre å omfatte: etablere en sesjon for å kommunisere bytestrømdata (266) i IONET-beskjeder (240), hver sesjon omfatter to halvsesjoner, kommunisere første IONET-beskjed fra en første kilde/destinasjonsinnretning til den andre kilde/destinasjonsinnretning i en halvsesjon, og kommunisere et svar IONET-beskjed fra den andre kilde/destinasjonsinnretningen til første kilde/destinasjonsinnretning i den andre halvsesjonen.

22. Framgangsmåte i samsvar med krav 21, karakterisert ved videre å omfatte: kommunisere statusinformasjon (268,270) angående foreliggende og tidligere halvsesjoner med hver svar IONET-beskjed.

23. Framgangsmåte i samsvar med krav 21, karakterisert ved videre å omfatte: i kommunisere en IONET-beskjed (240) for å vedlikeholde flyten i en etablert sesjon når bytestrømdata (268) er utilgjengelig for å kommunisere ved IONET-datapakkebeskj edene (240).

24. Framgangsmåte i samsvar med krav 21, karakterisert ved videre å omfatte: tolke funksjonskoden (270) og administrativ informasjonskode (264) og utføre en tilsvarende styringsfunksjon på en av kilde/destinasjonsinnretningene eller grensesnittet (182) mens sesjonen er etablert, og kommunisere en svar IONET beskjed for å indikere om styringsfunksjonen ble vellykket utført, i

25. Framgangsmåte i samsvar med krav 21, karakterisert ved videre å omfatte: inkludere rekkefølgeinformasjon (268) i en I/O-nett-datapakkebeskjed (240) på en halvsesjon som spesifiserer sekvensiell orden ved flere datapakker (240), og kvittere i en svar I/O-nett-beskjed i den andre halvsesjonen de av datapakkene (240) som ikke har blitt vellykket mottatt.

26. Framgangsmåte i samsvar med krav 25, karakterisert ved videre å omfatte: retransmittere de av datapakkene (240) som har blitt kvittert som ikke vellykket mottatt.

27. Framgangsmåte i samsvar med krav 21, karakterisert ved videre å omfatte: retransmittere I/O-nett-datapakkebeskjeder (240) som tidligere har blitt transmittert etter utgang av en gitt tidsperiode etter hvilken svar I/O nettbeskjed som kvitterer mottak av de beskjeder som ikke har blitt mottatt.

28. Framgangsmåte i samsvar med krav 20, karakterisert ved videre å omfatte: etablere en sesjon mellom de av kilde/destinasjonsinnretningene som er forvalgt til å tillate kommunikasjon av I/O nettbeskjeder (240) seg imellom.

29. Framgangsmåte i samsvar med krav 20, karakterisert ved videre å omfatte: dele opp de administrative og bytestrøm datafeltene (264,266) ved hver I/O nett-beskjed inn i vilkårlig lengder, der hver av disse kan inneholde ingen informasjon, og spesifisere lengden på hver av de administratrive og bytestrøm datafelt (264,266) ved å sette inn karakterer i I/O nett-overskriftfelt (260) som danner en lengdekode (282,284).

30. Framgangsmåte i samsvar med krav 20, karakterisert ved videre å omfatte: kommunisere flere I/O-nett-databeskjeder (240), og begrense antall I/O-nett-datapakkebeskjeder (240) kommunisert i en gruppe til et antall som i det minste er én mindre enn det antall I/O-nett-datapakkebeskjeder (240) som kan mottas i lageret ved en destinasjonsinnretning uten å hindre et mottakerorgan ved en destinasjonsnode (174).