Lamer SC - ATM



















Główna strona



Firma



Rozwiązania



Produkty



Wsparcie













Dokumentacje





  ATM





  GtkADA





  PostgreSQL





  XML










ATM

I. Wstęp.
Podstawowy opis standardu ATM
Standard ATM (Asynchronous Transfer Mode)
został ujęty w zaleceniach ITU-T jako podstawowy
składnik realizujący połączenia w sieciach B-ISDN będących
szerokopasmowym rozszerzeniem znanej już sieci ISDN. Standard
ATM zdefiniowany jest jako specyficzny rodzaj
transferu wiadomości oparty na przesyłaniu pakietów z
wykorzystaniem techniki asynchronicznej multipleksacji z
podziałem czasu. Multipleksowany strumień informacji jest
zorganizowany w jednakowej długości bloki zwane
komórkami (pakietami). Pakiet składa się z pola
informacyjnego oraz nagłówka. Podstawową rolą nagłówka jest
identyfikowanie pakietów należących do jednego kanału
wirtualnego. Pakiety są przypisywane na żądanie, w zależności
od aktywności źródła i dostępnych zasobów sieci. ATM jest
techniką zorientowaną na połączenie. Połączenie widziane z
poziomu warstwy ATM składa się z jednego lub kilku łączy, z
których każde ma przypisany identyfikator. Identyfikatory te
pozostają niezmienne przez cały czas trwania połaczenia.
Sygnalizacja dotycząca danego połączenia jest przekazywana
przy użyciu odrębnego identyfikatora. Informacja w
standardzie ATM jest przesyłana w postaci komórek (pakietów)
oznaczanych nagłówkiem. Długość komórki wynosi 53 bajty, przy
czym 48 z nich stanowi w tym wypadku informacja, zaś
5-nagłówek. Komórki, które należą do jednego połączenia tworzą
kanał wirtualny (ang. Virtual Channel). W każdym łączu
fizycznym transmitowane są komórki należące do różnych
połączeń. Każdemu połączeniu odpowiada w łączu jeden kanał
wirtualny. To, do którego kanału wirtualnego należy dana
komórka rozpoznawane jest na podstawie pól VCI (Virtual
Channel Identifier) i VPI (Virtual Path Identifier).
Kanał wirtualny może być traktowany jako
jednokierunkowe łącze logiczne pomiędzy dwoma węzłami sieci
lub użytkownikiem a węzłem sieci. Z tych samych łączy
fizycznych może jednoczenie korzystać wiele kanałów
wirtualnych. Pakiety informacji mogą być wysyłane z dowolną
(ustaloną na etapie zestawiania połączenia) prędkością
transmisji i innymi parametrami (np. wybuchowością). Kanał
wirtualny może cechować się dowolnie szeroką przepustowością
(oczywiście dopuszczalną przez łącze fizyczne). W
sieci ATM realizowane jest połączenie typu kanał wirtualny-VCC
(Virtual Channel Connection), które oznacza zestawienie pewnej
liczby łączy typu kanał virtualny VCL (Virtual Channel Link) w
celu utworzenia trasy pomiędzy dwoma punktami dostępu do sieci
ATM (VCC end-points) dla przezroczystej transmisji informacji.
Połączenia typu kanał wirtualny są połączeniami
jednokierunkowymi są tworzone przez jednokierunkowe łącza VCL.
Stworzenie połączenia dwukierunkowego wymaga więc zestawienia
pary połączeń typu VCC, osobnego dla każdego kierunku.
Połączenia typu kanał wirtualny (VCC) mogą mieć strukturę
wielopunktową (point-to-multipoint lub multicast)
wykorzystywaną w przypadku usług rozgłoszeniowych lub
konferencyjnych. Ogólnie rzecz biorąc połączenia typu kanał
wirtualny VCC mają znaczenie globalne, zaś łącza VCL lokalne
na danym odcinku połączenia. Standard ATM jest
techniką telekomunikacyjną typu połączeniowego. Oznacza to, że
faza przekazywania właściwej informacji jest poprzedzona fazą
zestawiania połączenia. W fazie wstępnej następuje tzw.
negocjowanie kontraktu pomiędzy klientem a administracją
sieci. Na podstawie parametrów sygnału (przepływności,
wybuchowości) klarowanych przez abonenta (i jego terminal)
sieć decyduje, czy w danej chwili (przy aktualnym obciążeniu
systemu) można zapewnić wymaganą jakość obsługi pojawiającego
się zgłoszenia i wszystkich innych aktualnie analizowanych.
Zadeklarowane warunki mogą być renegocjowane w czasie trwania
połączenia, jednak możliwość renegocjacji jest zwykle przez
sieć redukowana. W czasie obsługi zgłoszenia wszystkie pakiety
przesyłane są jedną trasą. Redukuje się przez to
niebezpieczeństwo utraty integralności informacji.
Przyporządkowanie konkretnego pakietu do danego kanału
virtualnego odbywa się na podstawie pola nagłówka zwanego
identyfikatorem kanału wirtualnego VCI (Virtual Channel
Identifier). Pole to musi mieć odpowiednio duży rozmiar, tak,
aby umożliwiać jednoznaczne rozpoznanie odpowiednio dużej
liczby kanałów wirtualnych w danym kanale fizycznym. Przy
stosowanych dużych przepustowościach medium sygnału jest to
duży problem zważywszy, że pole VCI musi jednak być
jednocześnie jak najmniejsze, gdyż jako pole nagłówka stanowi
narzut obniżający faktyczną przepustowość systemu. W
stosowanych rozwiązaniach pole to nie ma znaczenia globalnego,
stosuje się pola 16-bitowe, które mogą być zmieniane (podlegać
translacji) w punktach zakończeń łączy wirtualnych VCL
(punktach komutacyjnych kanałów wirtualnych-virtual channel
switching nodes).
Protokoły AAL
Zdefiniowano cztery protokoły warstwy
adaptacji ATM:

AAL1 - wspomaga usługi połączeniowe - klasę usług "A".
Wymagają one stałej prędkości transmisji (ang. CBR -
Constant Bit Rate), charakteryzują sie uzależnieniem
czasowym pomiędzy nadawcą a odbiorcą (taktowanie i
opóźnienie) i wymagają od sieci przeniesienia zawartej w
nich informacji o taktowaniu. Przykładem takiej usługi może
być transmisja video.
AAL2 - (klasa usług "B") - wspomaga usługi połączeniowe,
wymagające zmiennej (przydzielanej dynamicznie) prędkości
transmisji (ang. VBR - Variable Bit Rate) i
zachowania zawartej w nich informacji o taktowaniu. Innymi
słowy usługi o zmiennej prędkości strumienia danych jak
niektóre standardy video (MPEG).
AAL3/4 - (klasy usług "C" i "D") - wspomaga usługi o
zmiennym zapotrzebowaniu na przepustowość, zarówno
połączeniowe, jak też bezpołączeniowe. Początkowo istniały
dwa oddzielne protokoły AAL3 oraz AAL4 odpowiednio dla usług
połączeniowych i bezpołączeniowych. Zostały jednak połączone
w jeden, nazywany AAL3/4.
AAL5 - wspomaga usługi połączeniowe o zmiennym
zapotrzebowaniu na przepustowość. W stosunku do AAL3/4 jest
on wersją znacznie odchudzona m.in. poprzez uproszczenie
korekcji błędów. Dzięki temu większe pole w komórce ATM
przeznaczone jest na informacje użytkownika (warstwy
wyższej). Upraszcza się także obróbka komórki oraz
implementacja protokołu. Zakwalifikowano go jako
wspomagającego klasę usług "C", chociaż istnieją projekty
wykorzystania go do transportu usług bezpołączeniowych
(projekt ATM Forum - "LAN-emulation" oraz specyfikacja IETF
dotycząca transportu protokołu IP przez sieć ATM).
II. Realizacja praktyczna
1. Implementacja ATM
a) sprzęt:
Do wykonania projektu użyliśmy komputera
klasy PC opartego na procesorze Intel Pentium, zaś jako
połączenie z siecią ATM, służyła nam karta ForeRunnerLE 25M
firmy ForeSystems, którą należało w zwykły sposób umieścić w
slocie PCI komputera. Karty te są ogólnie uznawane za
najpopularniejsze urządzenia ATM - 25 Mbit, o czym świadczy
ich ogromna popularność wsród użytkowników komputerów
domowych. Potwierdza się to także wsród członków list
dydskusyjnych poruszających tematykę ATM i jego implementacji
w systemach Unixowych. Przeważająca ich większość posiada
karty tego typu, lub (w wypadku Europy zachodniej) droższe
modele 155 Mbit.
b) system
Jako system, na którego platformie
zainstalowaliśmy obsługe ATM, wybraliśmy Linuxa. Przy
realizacji poprzedniego projektu również korzystalismy z
niego, zatem nie było potrzeby instalacji nowej platformy.
Dystrybucją jaką wybraliśmy, jest Redhat, chociaż jest on
uznawany za najbardziej "trudny" system. Oczywiście nie chodzi
nam tu o obsługę, gdyż ta w przypadku redhata jest
najłatwiejsza (w porównaniu do np. slackware'a), tylko o
szanse "opanowania" skomplikowanych awarii i niepowodzeń w
konfiguracji. Chociażby ze względu na stopień zagmatwania jego
skryptów konfiguracyjnych nie jest on odpowiedni do
zastosowań, w których liczy się pełne panowanie nad systemem i
rozumienie go "na wylot". Nasz system opierał się na
standardowej dystrybucji RedHata - 6.0 Hedwig. Pod koniec
projektu, kiedy wychodziły kolejne wersje sterowników do ATM
nasz system jednak zupełnie nie przypominał standardowej
odmiany RedHata. Stabilne jądro 2.2.5-15 zostało kilkukrotnie
wymieniane na rozwojowe jądra serii 2.1.1xx zaś pod koniec
realizacji projektu pojawiło się jądro 2.3.99-pre3 - zatem
oparliśmy się na nim. Również wszystkie pakiety były na
bieżąco wymieniane na nowsze. Tu szczególnie uwidacznia się
zaleta formatu RPM, gdyż nie musieliśmy tracić czasu na
uaktualnianie bibliotek i pokonywanie trudności
konfiguracyjnych, tylko mogliśmy koncentrować się na
implementacji ATM.
c) oprogramowanie
Aby w najprostszy sposób zaimplementować ATM
na systemie Unixowym, należy udać się na stronę: http://lrcwww.epfl.ch/ .
Stamtąd należy pobrać sterowniki. Na tamtejszym ftp-ie można
wybrać dowolną wersję "pasującą" do jądra, które w danej
chwili posiadamy, ale oczywiście najlepiej jest wybrać jak
najnowsze pakiety. Jednak różnica między kolejnymi ich
wersjami jest z biegiem czasu coraz mniejsza, ponieważ
człowiek, który koordynuje rozwój projektu Linux/ATM - Werner
Almesberger opracował kompletny zestaw usług i teraz następuje
już tylko poprawianie błędów. Powoli także jego pakiet
przypomina profesjonalnie działającą, niezawodną aplikację,
którą można śmiało stosować w rozwiązaniach komercyjnych.
Początkowo opieraliśmy się na pakiecie ATM-0.52, jednak z
powodu trudności jakie napotykaliśmy, a jakie opiszemy nieco
później, został on wymieniany na kolejne nowsze wersje, aż do
wersji ATM-0.72, która działała już w pełni stabilnie.
d) lista dyskusyjna
Dla osób zainteresowanych zagadnieniem lub
napotykających praktyczne problemy przydatna może okazac się
lista: [e-mail]
W naszym wypadku nie miała ona decydujacego wpływu na rozwój
działań, poza informacjami o kolejnych, nowych sterownikach.
Pod koniec projektu jednak skierowaliśmy na nią pytanie, gdyż
napotkaliśmy bardzo ciekawy problem, który wydawał się nie
mieć logicznego rozwiązania.
2. Konfiguracja
Aby wykorzystać standard ATM w systemie
Linux, należy przed kompilacją odpowiednio "spatchować" jadro,
aby umożliwić mu obsługę ATM-u. Dokonujemy tego poleceniem: patch -s -p1 < /atm.patchPlik atm.patch
zawarty jest w pakiecie ATM - 0.xx. W jego skład wchodzą
ponadto: dokumentacja w kilku formatach, podstawowe demony
sieciowe, programy użytkowe i programy testujące. Po
"poprawieniu" jądra "łatką" można przystąpić do instalacji
pakietu ATM-0.xx. Pakiet ten jest wyposażony w odpowiedni plik
Makefile, a więc wystarczy w jego głównym katalogu wykonać
polecenie "make". Nastepnie możemy przystąpić do konfiguracji
jądra. Po zastosowaniu "łatki" powinny pojawic się nowe,
dotychczas nie spotykane opcje. Rzeczywiście po przejściu do
katalogu: /usr/src/linux-2.3.99-pre3i wydaniu polecenia: make menuconfigmożna zauważyć kilka nowych,
odpowiadających ATM pozycji, możliwych do skonfigurowania. Oto
one, podane w wersji angielskiej, gdyż cały pakiet z pewnościa
nigdy nie będzie lokalizowany: Asynchronous Transfer Mode (ATM, EXPERIMENTAL) (CONFIG_ATM)
Use "new" skb structure (CONFIG_ATM_SKB)
Classical IP over ATM (CONFIG_ATM_CLIP)
Do NOT send ICMP if no neighbour (CONFIG_ATM_CLIP_NO_ICMP)
LAN Emulation (LANE) support (CONFIG_ATM_LANE)
Multi-Protocol Over ATM (MPOA) support (CONFIG_ATM_MPOA)
ATM over TCP (CONFIG_ATM_TCP)
Efficient Networks ENI155P (CONFIG_ATM_ENI)
Enable extended debugging (CONFIG_ATM_ENI_DEBUG)
Fine-tune burst settings (CONFIG_ATM_ENI_TUNE_BURST)
Enable 16W TX bursts (discouraged) (CONFIG_ATM_ENI_BURST_TX_16W)
Enable 8W TX bursts (recommended) (CONFIG_ATM_ENI_BURST_TX_8W)
Enable 4W TX bursts (optional) (CONFIG_ATM_ENI_BURST_TX_4W)
Enable 2W TX bursts (optional) (CONFIG_ATM_ENI_BURST_TX_2W)
Enable 16W RX bursts (discouraged) (CONFIG_ATM_ENI_BURST_RX_16W)
Enable 8W RX bursts (discouraged) (CONFIG_ATM_ENI_BURST_RX_8W)
Enable 4W RX bursts (recommended) (CONFIG_ATM_ENI_BURST_RX_4W)
Enable 2W RX bursts (optional) (CONFIG_ATM_ENI_BURST_RX_2W)
ZeitNet ZN1221/ZN1225 (CONFIG_ATM_ZATM)
Enable extended debugging (CONFIG_ATM_ZATM_DEBUG)
Enable usec resolution timestamps (CONFIG_ATM_ZATM_EXACT_TS)
IDT 77201 (NICStAR) (CONFIG_ATM_NICSTAR)
Use suni PHY driver (155Mbps) (CONFIG_ATM_NICSTAR_USE_SUNI)
Use IDT77015 PHY driver (25Mbps) (CONFIG_ATM_NICSTAR_USE_IDT77105)
Madge Ambassador (Collage PCI 155 Server) (CONFIG_ATM_AMBASSADOR)
Enable debugging messages (CONFIG_ATM_AMBASSADOR_DEBUG)
Madge Horizon [Ultra] (Collage PCI 25 and Collage PCI 155 Client)
Enable debugging messages (CONFIG_ATM_HORIZON_DEBUG)
Interphase ATM PCI x575/x525/x531 (CONFIG_ATM_IA)
Enable debugging messages (CONFIG_ATM_IA_DEBUG)
Jądro kompilujemy standardowym zestawem komend:
make dep, make clean i make (b)zImage. Skompilowane właśnie
jądro znajduje się w katalogu: /usr/src/linux/arch/i386/boot/i rezyduje tam jako
plik "bzImage". Nastepnie kompilujemy moduły poleceniami make modulesi make modules_install
Podczas zmiany ze starego jądra (2.2.5-15) na
nowsze, pojawił się szereg problemów, gdyż żadna z
niestabilnych wersji zalecanych w kolejnych pakietach ATM nie
chciała współpracować z naszą kartą sieciową. Prawdopodobnie
było to spowodowane tym, że wykorzystuje ona standard ISA,
który nie jest już wspierany przez nowe jądra. Podobne
problemy pojawiły się podczas konfiguracji tunelu przy
poprzednim projekcie.Dopiero po instalacji jądra
2.3.99 nasza karta zaczęła działać bez zarzutu, jednak na
walkę z zaistniałymi problemami poświęciliśmy bardzo dużo
czasu. Podobnie starsze niestabilne jądra nie chciały
współpracować z naszą kartą ATM. Karta nie zgłaszała się
podczas startu systemu, zaś polecenie atmdiag nie
pokazywało żadnych statystyk wykrytego urządzenia. I tu
również rozwiązaniem problemu okazało się zainstalowanie
nowego jądra. Z uwagi na to, że na innych komputerach nie było
podobnych problemów, podejrzewaliśmy, że podobnie jak w
poprzednich przypadkach wystąpiły problemy ze sprzętem.
Innym ciekawym zjawiskiem, jakie napotkaliśmy, było
to, że karta ATM nie "wstaje", gdy restartujemy komputer z
wpiętym w kartę loopbackiem (czyli krótkim przewodem łączącym
pin 1 z 7 i 2 z 8). Było to bardzo uciążliwe, gdyż po każdym
restarcie komputera (np. z powodu częstych na katedrze
chwilowych awarii zasilania) musieliśmy osobiście "nadzorować"
start systemu. Procedura uruchamiania karty musiała przebiegać
według ściśle określonego scenariusza: najpierw należało wyjąć
kabel-loopback z karty ATM, następnie zrebootować system i po
zgłoszeniu się urządzenia ponownie włożyc przewód. Jest to
sprzeczne z tym, co ogólnie wiadomo o kartach ForeSytem. Karty
te w wielu przypadkach nie "wstają", gdy nie mają włożonego
żadnego przewodu do gniazda. Jeden z pracowników Katedry
Telekomunikacji, specjalizujący sie w technologii ATM również
potwierdził tę opinię. Z naszym problemem
skierowaliśmy więc się na listę, zaś odpowiedzi udzielił nam
jeden z ludzi koordynujących projekt ATM/Linux - Greg Banks.
Przytaczamy jego wypowiedź w całości, zaś później pozwolimy ją
sobie krótko skomentować: The PHY driver for the LE25 detects loss of signal when you pull out
the old cable (or start the system without the cable). It then turns
off transmit, which has a side effect of turning off carrier, and puts
itself into a state where it waits for a carrier on the line before
restarting transmit. If you insert a loopback cable, there is of course
no carrier to detect because it would have been the one we just turned
off, so basically the driver is waiting for something which never happens.


This is unfortunate, as it makes it unnecessarily difficult to use
loopback cables. However, there are two work-arounds.

1. have the loopback cable already inserted when you boot the
system (or reload the module), or

2. (better) use the software-controlled loopback feature of the
card, which you can access using the `atmloop' utility. Then
you don't need the loopback cable at all, just leave the normal
cable connected.

Niestety i ta wypowiedź mija się z prawdą (a
zwłaszcza punkt 1, punkt 2 nie interesuje nas zupełnie w
naszym rozwiązaniu, zaś o pętlach "programowych" napisaliśmy
przy okazji omawiania polecenia atmloop), zatem problem ten
odłożyliśmy do wyjaśnienia na czas nieokreślony. Wyszliśmy z
założenia, że skoro G. Banks nie jest w stanie nam pomóc, zaś
inni "wielcy" listy linux/ATM nie odpowiedzieli nam nawet na
nasze pytania (łącznie z Wernerem Almesbergerem), to
prawdopodobnie nie znajdziemy już przyczyny dziwnego
zachowania naszej karty.
3. Opis pakietu ATM-o.xx
W skład pakietu, oprócz standardowego
oprogramowania do implementacji ATM w systemie Linux, wchodzi
także cały szereg programów użytkowych. Okazują się one bardzo
przydatne podczas konfiguracji interfejsu ATM. Postaramy się
teraz omówić krótko najważniejsze:
a) atmdiag
Najważniejszym chyba poleceniem zaraz po
pomyślnej instalacji karty (oczywiście obok "obowiązkowego"
dmesg) jest polecenie: atmdiag

Program ten (napisany oczywiście przez
Almesbergera) pokazuje statystyki urządzenia ATM. Jeśli
zainstalowane są jakieś inne karty - atmdiag pokaże także ich
parametry. Wśród nich znajdują się:
TX_okay - liczba poprawnie przesłanych PDU
TX_err - liczba nie wysłanych PDU (mogło to być
spowodowane np. błędami)
RX_okay - liczba odebranych PDU
RX_err - liczba nie odebranych PDU z powodu błędów
RX_drop - liczba nie odebranych PDU z powodu braku
dostepnej pamięci. Wynik działania polecenia przedstawia się w
wypadku poprawnie wykrytego interfejsu ATM nastepująco: Itf TX_okay TX_err RX_okay RX_err RX_drop
0 AAL0 0 0 0 0 0
AAL5 18 0 18 0 0


Liczby wysłanych i odebranych pakietów są
identyczne ponieważ test był robiony przy założonej pętli
loopback oraz transmisja odbywała się bez błędów.
b) atmloop
Polecenie to konfiguruje i pokazuje
obowiązujące ustawienia pętli loopback (ale programowej).
Pętlę taką można skonfigurować na wiele ciekawych sposobów.
Dla osoby przyzwyczajonej do użytkowania sieci Ethernet opcje
te mogą wydac się nieco "egzotyczne". Oto one:
pętla na poziomie PDU
pętla na poziomie komórek ATM
"cyfrowa" pętla na poziomie bitów
pętla na poziomie analogowym opcje te wywyołujemy z
parametrem -t . Inne parametry to -i - pokazuje ustawienia
oraz -c , który powoduje wprowadzenie priorytetów. Polecenia
tego nie wykorzystywalismy w naszym projekcie. Oczywiście
można śmiało postawić znak równości pomiędzy naszym
loopbackiem zrealizowanym za pomoca przewodu, a czwartą wersją
pętli programowej.
c) atmaddr
Kolejny program napisany przez Wernera
Almesbergera. Pozwala on na monitoring adresów przypisanych do
inrterfejsu ATM. Pozwala także na ręczną zmianę tych adresów,
ich dodawania oraz usuwanie. Oto podstawowe opcje: -a
dodaje adres do interfejsu -d usuwa adres z interfejsu
-r resetuje (czyści) listę adresów lokalnego interfejsu
Z tego programu również nie korzystalismy, gdyż
ustawienia adresów przenieśliśmy do źródeł naszych programów.
Równie dobrze można by jednak ustawienia te wywoływać
bezpośrednio w naszym programie np. poleceniem
"system(polecenie atmaddr z parametrami)". Prawdopodobnie
wszystkie programy użytkowe, jakie zawarł w swoim pakiecie
Almesberger, są to front-endy na bibliotekę libatm.a, z której
podczas pisania naszych programów korzystaliśmy, ale jednak w
nieco inny sposób - wywołując zmianę opcji bezpośrednio jako
pola struktur. Podobnie nie skorzystaliśmy z napisanej
ostatnimi czasy przez Almesbergera dosyć ciekawej funkcji (ale
oczywiście sprawdzalismy i testowaliśmy jej działanie).
Funkcja ta to text2atm( ... ). Pozwala ona na automatyczne
przeniesienie adresacji ATM do prostej postaci tekstowej.
Należy jedynie podać jej jakiś string o ściśle określonej
formie, gdzie kolejne numery oddziela się kropkami, po czym
samoczynnie funkcja ta ustawia odpowiednie pola struktury
atm_addr.
III. Opis programu
Oprócz skonfigurowania i uruchomienia ATM w
systemie Linux, chcieliśmy także poznać metody pisania "pod"
tego typu sprzęt. Początkowo mieliśmy trudności z biblioteką
do ATM-u (libatm.a), która wywoływała konflikty z innymi
bibliotekami w naszym systemie - zwłaszcza tymi
odpowiedzialnymi za sprawy sieciowe. Problem, po długo
trwających próbach, rozwiązaliśmy nastepująco:

podmieniliśmy niezbędne biblioteki (głównie wywołujace
konflikt biblioteki sieciowe) na te dołączone do pakietu
ATM-0.xx
zmodyfikowaliśmy plik netinet.h, który przy poprzednim
projekcie również był zmieniany (bezpośrednio to mogło być
przyczyną konfliktu). Prawdopodobnie plik ten obecnie
"powrócił" do swojej oryginalnej wersji.
Po przeprowadzeniu tych czynności problemy
zniknęły. Oprócz standardowej biblioteki do ATM-u,
korzystaliśmy także z graficznej biblioteki Gimp ToolKit,
znanej popularnie jako GTK+. Pozwala nam ona tworzyć programy
z graficznym interfejsem, działające w środowisku na serwerze
X-window. Programy jakie pisaliśmy (źródła ostatecznej wersji
dołączyliśmy do projektu) wykorzystują standardową transmisję
sieciową poprzez sockety. Po utworzeniu socketu (typ
PF_ATMPVC, transmisjja datagramowa) i odpowiednim jego
skonfigurowaniu (konfiguracja polega m.in. na ustawieniu
parametrów vpi i vci) można bezpośrednio do niego "wrzucać"
dane. Socket ten jest to zwykły deskryptor, który wskazuje
notabene na fizyczne urządzenie, czyli w naszym wypadku kartę
ATM. Program czyta zawartość pliku (plik może być dowolny,
nawet binaria zostaną także "przeźroczyście"
przetransportowane) a następnie umieszcza go w buforze, który
jest połączony bezpośrednio z kartą ATM. Urządzenie czeka
określoną ilośc czasu, tak aby dało się cały proces
zaobserwować (ustawiono domyślnie 10 sekund), po czym wysyła
dane na wyjście karty ? czyli na piny 1 i 2. Dane te
natychmiast "wracają" do urządzenia poprzez piny 7 i 8 (
zrealizowany jest loopback przewodem o długości 10 cm).
Kolejno następuje buforowanie przychodzących danych, ich
odczyt oraz umieszczenie w pliku, specjalnie w tym celu
przygotowanym. Po tym jak na wejściu karty pojawią się jakieś
dane, program zasygnalizuje ich obecność za pomocą np. sygnału
dzwiękowego lub zapalenia jednej z trzech diód na klawiaturze.
Ponieważ nasz program powstawał zdalnie (poprzez X-window)
używaliśmy drugiej możliwości. Także w wersji ostatecznej
zostawiliśmy sposób sygnalizacji diodami. Obserwację wejścia
karty powierzyliśmy najlepiej do tego celu nadającej się
funkcji "select", która przy minimalnym obciążeniu procesora
(pomimo ciągłej pracy) jest w stanie bez przerw monitorować
dany deskryptor. Gdy pojawią się na nim jakieś dane (w naszym
wypadku interesuje nas jedynie grupa możliwa do odczytu)
funkcja ta zasygnalizuje nam to poprzez chwilowe wyjście z
pętli monitorowania i wykonanie kilku odpowiednich czynności.
Z częscią projektu odpowiadającej pisaniu przesyłania danych,
nie mieliśmy żadnych problemów, na jakie napotykaliśmy podczas
instalacji i konfiguracji karty ATM.
Sławomir
[e-mail]

Literatura i www.
W. R. Stevens "Programowanie zastosowań sieciowych w
systemie UNIX"
Maurice J. Bach "Budowa systemu operacyjnego UNIX"
http:// www.gtk.org
http:// www.lrcwww.epfl.ch/linux
Dokumentacja dołączona do pakietów ATM-0.xx
Witryny poświęcone tematyce ATM oraz Linuxowi



   
    



Copyright 1999-2001
by Lamer SC