a las Redes de Computadoras
Flores S., Printista A.M., Molina S., PersioA., Apolloni R.
Departamentode Informatia
Universidad Naionalde San Luis
Ejerito delos Andes 950
5700 -San Luis
Argentina
e-mail: fsores,mprinti,persioa, smolina,rubengagunsl.edu.ar
Resumen
En este trabajo presentamos las onlusiones de la primera etapa planiada en un
proyetoeduativodenuestraFaultad.Comoobjetivosgeneralesnospropusimos
desarro-llarunaherramientaeduativaqueestuviese dirigidaa losalumnosavanzados denuestra
arrera,a travesde laurrulaorriente.La ideaes ofreerles unambito de disusion y
desarrollodisiplinarenestearea,nofuertementeabordadaennuestroDepartamento.De
estamaneratambienontribuiralaformaiondetesistas,beariosypasantesinteresados
en estatematia.
Conretamente, enestetrabajopresentamoseldise~nodeMonitorES,unMonitorde
EstadodeServidoresenunareddeomputadoras,trabajandoenunambienteTCP=IP.
Lamotivaionprinipaldeldesarrollode estaprimeraetapaestuvobasadaenelsiguiente
onepto: paradise~nar eientementeapliaionesdistribuidas, primero hay que
familia-rizarse y onoerla performane de la r edsobrela quese implementara la apli aion.
Unaonseueniainmediata delproyetofue la formaion de reursoshumanosen el
area altamente r tiade redes, produiendo un aeramiento amigable de usuarios no
expertos enla tematia.
Palabras Claves:
Monitor, Performane, Metria,TCP/IP, Cliente-Servidor.
GruposoportadoporlaUNSL(ProyetoEduativoP-3-0387/02yProyetodeInv.P-338403)ylaANPCYT
Muhos a~nos dediados ala doeniay ala investigaion, alalogodi y altrabajo on doentes
y alumnosprovenientes de distintas formaiones, han delimitadoun deterioro de intereses
o-munes on respeto a la ense~nanzay a los modos posibles de intervenionpara partiipar
ativamenteen el proesode las transformaioneseduativasqueen distintosniveles se vienen
produiendo. Los problemas que se fueron planteando en el ampo de la tenologa,onduen
a lainstrumentaiondeabordajes metodologios alternativos.
La pratiadoente debe organizar la esena en la que se vinulan los sujetos a travesdel
onoimiento,en esteontexto esque serealizalainseriondelusode laherramientaon nes
didatios.
La mayorade los integrantes de esta propuesta somos doentes de atedrasde la arrera
Lieniatura en Cienias de la Computaion. En nuestraspratiasse utiliza software de alto
nivel para aeder a los serviios de una red. Sin embargo se peribe que, el interesde los
alumnosporonoer mas profundamente elproeso real de omuniaionentre omputadoras
(aspeto que es oultado por el software de alto nivel), ha reido onsiderablemente en los
ultimos a~nos.
Esto se debe a que los alumnos en la ultima deada,periben omo natural y orriente
sentarse a desarrollar y ejeutar sus apliaiones sobre una red masque sobre elviejo modelo
de uniaomputadora.
Lo expresado en losparrafos anteriores,fueron entre otras,motivaionesquellevaron,en la
atualizaiondelplandeestudiodelaLieniatura,areformularlamateriaSistemasOperativos
por Sistemas Operativos y Redes. Aompa~nando este proeso de ambio y atualizaion, un
grupo de doentes, insistimos en la neesidad de generar un ambito de disusion, interambio
y experimentaionen el tema, a n de formar y perfeionar a los doentes involuradosy
habilitarlosparaquelatransfereniadelosonoimientos,relaionadosaesteareadeemergente
tenologa, seaonsistente.
Como objetivosgenerales seestableiodesarrollar una herramientaeduativa queestuviese
dirigida a losalumnos avanzados de nuestraarrera, a travesde la urrulaorriente. Podra
diretamente atuar de apoyoen las atedras\Sistemas Operativos y Redes", \Arquitetura
II", \Sistemas Distribuidos y P aralelismo"y \Redes de Computadoras"; pero tambienque
ontribuyese a la formaion de tesistas, bearios y pasantes interesados en esta tematia. La
idea es ofreerles un ambito de disusiony desarrollo disiplinar en este area, no fuertemente
abordada en nuestroDepartamento.
Como onseuenia resultola idea de onstruir la herramienta estableiendo los siguientes
objetivos espeos:
Lograr una herramienta eduativa,de estrutura modularde maneratalque sea senilla
su manipulaion.
Lograr el desarrollo de una Interfasede Programas de Apliaion (API) que failite el
desarrollode apliaiones distribuidas.
Lograr quela mismaherramientarealie laoleionde datos quefailiten laevaluai on
deomplejidad.Enprimerlugar,lograrunaeramientoamigablequepermitieraeltratamiento
experimental de los aspetos relaionados a las redes, onoer su omportamiento, topologa
y performane. En segundo lugar, permitir que ada usuario onstruya sus propias soliitudes
de aeso a los serviios de la red, a travesde iertos programas generios (esqueletos) que lo
abstraeran de detallesde estruturas y de omuniaiones entre lasomputadoras. Finalmente
losusuariospodranre-programar,porlasondiionesenqueestaranonstruidoslosprogramas
generios,ualquier subonjunto de las apas queonforman laherramienta.
2 Introduion
Enlatenologade omputadoraselenfoquetradiional delasultimas deadasfueevoluionar
haia multiproesadores o superomputadoras [5,7℄.Atualmente, en los pases desarrollados
existe una tendenia que plantea ejeutar las apliaiones distribuyendolasentre varios
proe-sadores de diferente poder omputaional. Las argumentaiones a favorde esta tendenia se
basanen onsideraiones eonomiasy de eienia.Desdeelpuntode vistadelosusuarios,se
hadifundidoelusode sistemasen redon elobjetivode ompartirarhivos,reursos,
informa-ion (internet),el uso del orreo eletronio,et. Sin embargo las posibilidades que brinda la
onexionenreddeunonjuntodeomputadorasson muhomasampliasqueladifundidaentre
usuarios orrientes. Aun resta generalizar omorealizarlas ejeuiones remotas de programas
sobre una red, el aeso a bases de datos remotas, omogenerar ambientes omputaionales
distribuidos, omodesarrollar omputaiones paralelasy omorealizardesarrollos sobre redes
que involureninteligeniaomputaional.
Hay un numero de problemas fundamentales asoiados al uso generalizado de las redes,
espeialmenteuandoelambientedistribuidosoportadoporlaredestaenontnuoreimiento,
tanto en tama~no omo en omplejidad. Ante esta situaion, un administrador de sistemas
neesita herramientas que lo ayudena analizar la situaionatual y entonespoder predeir
el omportamiento futuro de los reursos y asesorar a desarrolladores de software aera del
rendimientode lared subyaente.
La Figura 1 muestra la visionde un usuario, a partir de su maquinafront-end. En ella se
observanladisponibilidaddedosherramientas,adaunaondistintosobjetivosydesarrolladas
en distintasetapas del proyeto.
La primera herramienta, MonitorES, ofree la posibilidad de monitorizar la ondiionen
queseenuentranlosservidores,enuantoadisponibilidadyperformane,atravesdedistintas
metriastalesomomemoriadisponible,utilizaiondeCPU,balanedearga,et.Enunfuturo
se espera que asista en el analisis y experimentaionde todos los aspetos relaionados a la
onexion, omuniaiony performane de la red.
La segunda herramienta, onsistira de una librer aexible de esqueletos algortmiosque
permita failmente el dise~node apliaiones distribuidas del tipo TCP/IP. Cada esqueleto
se orresponde on un paradigma lasiode omputaion distribuida. La palabra paradigma
es a menudo usada on una onnotaion general omo "metodologasde alto nivel que se
reonoen en mu hosde nuestrosalgoritmosefetivos". Eneste trabajo se usara elterminoen
unsentidomaspreiso:unparadigmade programaiones unalasedealgoritmosqueresuelven
problemasdiferentes perotienen la misma estrutura de ontrol. Estos programas a menudo
espeos.Un esqueleto inluye tipos de datos no espeiados y proedimientos que varan
de una apliaion a otra. Un programa modelo luego se obtiene reemplazando estos tipos de
datos y proedimientos on los tipos de datos orrespondientes y on los proedimientos que
onstituyen elprograma seuenial que resuelve elproblema espeo.
USUARIOS
Libreria de
Esqueletos
API
MonitorES
0
1
0
0
1
1
0
1
0
0
1
1
0
1
0
0
1
1
0
1
0
0
1
1
Figura1: API:ProyetoEduativo
3 MonitorES
La monitorizaion de una oleion de hosts es neesaria para la administraion, tanto de las
redes de omuniaionomo para lossistemas distribuidos que seejeutan en ella.
Como se muestra en la Figura 2 la informaion reoletada es utilizada en la toma de
deisionesdeadministraionyenlaejeuiondeaionesapropiadasdeontrolsobreelsistema.
Control
Monitorear
Sistema Administrado
Datos Monitoreados
Accion de Control
Toma de Desiciones
Figura2:Modelo de Administraion de unSistema
En este trabajo nosotros disutimos prinipalmente la monitorizaion de un onjunto de
hosts, en partiular el uso de un monitor omo una herramienta de aeramiento y de
admin-istraion.Las aiones de ontrol que pueden ambiar el estado de una red de servidores son
en ambios de estado.
Las aiones de monitorizaionson ejeutadas sobre un reurso o grupos de reursos
rela-ionados. Unreurso esdenido omoualquier omponentede hardware (oeventualmentede
software) uyo omportamiento puede ser ontrolado por un sistema de administraion. Este
reurso tiene una atividad propia, intrnseaa su deniion y uyos detalles internosson de
vitalimportaniapara lospropositos de la monitorizaion.
La informaionde monitorizaiondesribeel estadoy los even tosasoiadoson un reurso
o un grupo de reursos que estanbajo estudio. Talinformaion puede ser representada por
reportes de estado individualeso por una seuenia de reportes.
El objetivode este trabajoesdenir un ambientede ontrolde servidoresapazde brindar
suiente informaion sobre el estado de los diferentes hosts que se quieren monitorear. La
informaion desribira la performane de los nodos a travesde distintas metriastales omo
memoriadisponible,utilizaionde CPU, balanede arga,et. Esta informaionserautilizada
porelmonitorparaonstruirunabasededatosquealmaenaravistashistoriasdelaatividad
de lared. Los reportes nales seranrequeridos bajo demanda de usuariosapropiados o
admin-istradores autorizados. A travesde una interfaseWeb, la informaion reoletada podra ser
manipulada, formateada o ltrada para ser reportada de modo que reunalos requerimientos
espeosde la apliaion.
3.1 Arquitetura del Monitor
Laarquitetura del monitorestabasada en un modelo Cliente-Servidor [5, 7℄omose muestra
en la Figura 3. Se puede observar la presenia de nodos (X;Y;Z) los uales atuanomo
lientes,denominadosmlientyunnodoqueseomportaomoservidor,denominadomserver.
Entre los proesos lientes y el servidor se implementa la funionalidad neesaria para que
MonitorES realie la reoleion, la lasiaiony el almaenamientode toda la informaion
de los multiples nodos de la red. Cada mlient estaraenargado de examinar su host loal
asoiado y de proporionar informaion referente al proesador, la memoria y otras metrias.
Las ehas que oneta ada proeso mlient on el proeso mserver estanrepresentando
el pasaje de mensajes, transmitiendo la informaion de estado requerida haia el servidor.
El proeso mserver, porsu parte, estaraenargado de reoletar los datos quele llegan desde
multiplesfuentesdelared,ordenarlosyalmaenarlosenbasesdedatosRoundRobin,R R D[8℄.
Elenvodepaquetesalmserverserealizaraaintervalosregularesdetiempo,vaTCP=IP [1,3℄.
Unproesomanagerseraelenargadode hequear dosarhivosdeonguraion: eldemetrias
y el de los hosts a monitorear. En aso de detetar un ambio de onguraion, este proeso
debera omuniarse on las maquinaslientes de MonitorES. Una interfase front-end,
provee una vista de la informaionatravesde un servidor Web.
Hay dos modos de operar on MonitorES: modousuario y modosuper-usuario. El modo
usuario permite a un usuario omun visualizar la performane de los host que omponen la
red, relativa a las metriasevaluadas.El modo super-usuario permite a un administrador de
red iniializar y modiar el pool de hosts a ser monitoreados, omo astambienativar las
mclient x
mclient y
mclient z
mserver:port
manager
Interfase Web
Arquitectura del Monitor
Back - end
Front - end
métricas
usuario común
super - usuario
clientes
rrds
Figura3:Arquitetura deMonitorES
3.1.1 Modulo Reoletor
EnestaseionsepresentandetallesdelfunionamientodeunmodulofundamentaldeMonitorES.
Conoer elestado de un onjunto de hosts, onstituye una herramienta fundamentalen la
buena administraion de una red. Identiar el uso de la memoria, la CPU, el diso y otras
variableslepermiten aladministradorde sistemasraionalizar eluso de losreursos.
El objetivo de MonitorES es hequearlos hosts de una red a intervalos regulares o bajo
demanda explita,y tomar aiones predenidas (no orretivas) uando un reurso no
re-sponde. Puede alertar de formavisual y sonora, enviarun e-mail a una asilla de orreo, a un
loalizadorotelefono movil,ejeutarprogramasexternos,et.Todasestasaiones permitenal
administradordesistemasoluionar un problemaantes del deterioro masivode laperformane
de la red o de lossistemas.
mserver
Es un proeso servidor que monitorea un onjunto de hosts. Este proeso espera por la
soliituddeomuniaionde algunproesomlient,enunpuertoonoido.Lospaquetes
que reibe onurrentemente de los nodos, los guarda en bases de datos Round Robin
(R R D)para su posterior proesamiento.
El proeso mserver almaena la informaion de estado de los hosts en bases de datos
Round Robin.Una base de datosRound Robin es unabase de datos irularquepermite
almaenar y representar datos en intervalos regulares de tiempo. Una araterstia
im-portante de una base de datos Round Robin es que al ser irular, su tama~no no ree
en eltiempo,esdeir,siempre ontiene lamisma antidad de datos,ya queuando
om-pleta la extension de la base de datos, simplemente sobreesribe a partir de los datos
mas antiguos. Las bases de datos irulares se rean en un arhivo on extension :rrd y
MonitorES utiliza laherramientaRRDtool para su proesamiento.
Estas failidades alertaran al administrador de sistema, sobre posibles adasen la
Es un proeso liente que se enuentra reoletando informaiondel estado de su nodo
loal. El proeso manager es quienestablee el tipo de metriaque ada mlient debe
reopilar.Estainformaionseenva,enformadepaquetes,almserverqueestaesperando
en un puertoonoido.
ElmodelodeomuniaionelegidoparaestemonitoressoketononexionusandoTCP=IP,
onseuentemente esuna omuniaionsinronia.Dentrodeeste esquema,elproesomserver
da a onoer un puerto por el ual los proesos mlient soliitan la omuniaion. Una vez
estableida esta omuniaion, ada mlient omienza a transmitir la informaion soliitada,
y seguiratransmitiendohasta que sedetete un ambiode onguraion.
3.2 Un Sitio Web omo Interfase de MonitorES
La interfase front-end de MonitorES es un sitio Web, por lo tanto estadisponible a
ualquier usuario de Internet,en espeial al administrador del sistema, que
independiente-mente del lugar en donde se enuentre puede realizar los ontroles neesarios, mejorando su
administraionen situaionesrtias, tomandodeisiones atiempo.
Lainterfase front-endde MonitorES esbasiamenteunaherramientadeonguraion
y la expresion graade toda la informaion reoletada por MonitorES (los valoresde las
metriasdeun host partiular).
Este sitioWeb permitedos modos de aesoa sus paginas,modousuario (paginas delibre
aeso) y modosuper-usuario (paginason aesorestringido).
Paginasde libre aeso sonpaginasorrespondientes almodode operaionusuario,on
a-esohabilitadoatodovisitanteWeb, permitenlaonguraiony visualizaiondelgrao
orrespondiente alosvalores de algunametriade unhost patiular. Laonguraionse
basaenlaseleiondeparametros,talesomo:metriaagraar,host paraadametria,
olor de lnea, anho, tipo de lnea, et.
Paginason aeso restringido son paginasorrespondientes almodode operaion
super-usuario, destinadas al uso del administradordel sistema, permiten onsultar y rear
in-formaionde onguraionpara el monitor.
La Figura 4 muestra la pagina a travesde la ual, ualquierusuario puede seleionar las
propiedades de una visualizaionpersonalizadade lasmetriasdeuno ovarioshosts.
La Figura 5 muestra la pagina de onguraion de Metrias-Hosts, aesible soloen
modosuper-usuario. Esta paginamanipulaelgrupode metrias, elgrupo dehosts disponibles
y permite espeiarel onjuntode metrias asoiadas aundeterminadohost.
Restringir el aesode un usuariodistinto deladministradordel sistema aiertas paginas,
formapartede nuestro meanismode proteion,para resguardarlainformaionde las
Figura5:MonitorES - Modo Super Usuario.html
La omuniaion de la interfase Web on el proeso manager, es deir la onexion del
front-end on el bak-end, se realiza mediante un arhivo de onguraion, y las bases de
datos Round Robin administradaspor elmserver.
El arhivo de onguraion ontiene: informaionde los hosts que se estan monitoreando,
el tipo de metriasque se estanevaluando para los hosts en uestiony los requerimientos
pendientesdeladministradordelsistema.Losrequerimientospendientesonsisteneninformarle
Lainterfasedelmonitorgeneralosgraosdelasdistintasmetriasapartirdelosvalores
almaenados en sus orrespodientes base de datos Round Robin. De esta manera, losusuarios
podranevaluar el funionamientodelsistema eientemente basandose en valores reientes.
3.3 Un Caso de Prueba
Las R R D son de gran utilidad para representar y monitorizar datos que puedan ser medidos,
omo por ejemplo lamemoriadisponible. A ontinuaionsemuestraun ejemplo de uso.
En partiular, MonitorES, en su versionDemo, realizouna monitorizaion de tres
servi-dores de uso intensivode laUniversidad.
Las Figuras 6 , 7 8 muestran los datos oleionados en tres hosts on el objetivo de
monitorizar, amedida que transurre el tiempo,su memoriadisponible. Enada gura, el eje
de oordenadas x representa el tiempo y el eje y representa la antidad en Megabytes de la
memoriadisponible en el host respetivo.
server srv1: on 384 Megabytes de memoria y on 7000 uentas de usuarios, brinda los
si-guientes serviios: POP (Post OÆe Protool), SMTP (Simple Mail Transfer Protool),
DHCP (DynamiHost Conguration Protool) y DNS (DomainName System).
Figura 6:MonitorES -Memoria Disponible:srv1
serversrv2:on128Megabytesdememoriayon600uentasdeusuarios,brindalossiguientes
serviios: SMTP (Simple MailTransferProtool, POP (Post OÆe Protool) y servidor
web APACHE.
server srv3: on 64 Megabytes de memoria y 500 uentas de usuarios, brinda los siguientes
serviios: POP (Post OÆe Protool), PPP (Point-to-Point Protool) y servidor web
APACHE.
Finalmente, en la Figura 9, se muestra el resultado de otra soliitud a MonitorES, a
travesde lainterfase front-end. El resultadoeseldesarrollodeuna graaomparativade
ladisponibilidaddememoriade lostres servidores,utilizandolainformaionreoletadadelas
Figura 8:MonitorES -Memoria Disponible:srv3
Figura 9:MonitorES - CuadroComparativo de MemoriaDisponiblede los tres servidores
3.4 Aporte de MonitorES
Generar un sistema de monitorizaion es una herramienta importante para la administraion
de una red.
Nosotros hemosdenido un modelode monitorizaionen terminosde un onjuntode
servi-ios. Lasprinipales funiones desriptas son: generaion de informaionde monitorizaion(a
travesdeunsistema reoletorde informaionelualinluyeelrelevamientodelestadode
tosde losusuariosvaWeb, realizalapresentaiongraa de lainformaionde monitorizaion
resultante.
Unode losaspetosatrativosde MonitorES esquenoesun monitorqueinterere
fuerte-mente en la performane o que altera la seuenia de atividades que ourren en una red.
MonitorES es un sistema independiente que se utiliza para reoletar informaion de estado
de iertosreursos.
Una funionimportante provista por MonitorES es el envo automatio de alertas que
ayudan al administrador de sistemas a tomar deisiones a tiempo, evitando que peque~nos
problemas setranformenen grandes problemas, debilitandoasla performane total de la red.
Aunque MonitorES este en estadode desarrollo,lo disutido enesta publiaiononrma
la utilidadde la herramienta para laadministraionde estado de losservidores de una red.
4 Trabajo Futuro: la onstruion nal de la API
Para reduir su dise~nola mayora de las redes estanorganizadas omo una serie de apas o
niveles y ada unaes onstruidasobre laapapredeesora. Lafunionde ada apa esproveer
iertos serviios a la apa mas alta, de manera que apas mas altas no traten on los detalles
de omo los serviios de apas subyaentes son implementados realmente. En ada nivel se
debera estableer un onjunto de reglas o protoolo que espeique su funionalidad. Esto es
neesarioparaestableeromuniaion(virtual)entreproesosqueorrenendistintasmaquinas
pero a un mismo nivel de la jerarquade apas. Es importante para el proyeto,en estado de
dise~no, tenerlaro dos aspetos:
Denirlaramentelas interfasesen trelasapas.
Espeiar elonjuntode funionesespeasque ada apadebe implementar.
Siestosdosrequerimientossonbiendenidosseminimizalainformaionquedebeuirentre
las apas, y tambiense failita elreemplazo de una apa on otra implementaiontotalmente
diferente que ofreza el mismo onjunto de funiones a sus apas veinaspero on un dise~no
distinto(omo ya fue menionadoes uno de nuestrosprinipales objetivos!).
Tanto el onjunto de apas omo el de protoolos onforman la arquitetura de la red.
(No forman parte de laarquitetura los detallesde implementaionnilas espeiaion de las
interfases).
4.1 Atividades globales
1. Realizar una espeiaion de la arquitetura que ontenga suiente informaion para
permitir que distintos implementadores esriban un programa para ada apa, de modo
que elprograma obedezaorretamenteal protoolo apropiado. Esmuy importante
re-saltarlaabstraionde losproesos queadministranlasapas. Sinesta teniasera muy
difilo imposible partiionar el dise~no ompleto en partes mas peque~nas y mas
apas. Es deir, en este punto yase ha deidido uales seranlos serviios que nuestra
red esta dispuesta a ofreer. En tal direionse debera preparar al prototipo para que
permitatransferirinformaionen sentido vertialennuestraAPI,reepionando y
entre-gandoinformaionentre lasapas.En estepuntoesde esperar lareformulaionen algun
sentidode laarquiteturapropuesta iniialmente,y aquepueden surgiraraterstiasno
ontempladas iniialmente o simplemente pueden surgir neesidades adiionales que no
apareieron en el momentode dise~no.
3. Implementarlasapasdelareddise~nada.Elonjuntodeapaseslaqueleproveerala
fun-ionalidadylaaraterstiapartiularalared.Comoyasedijoadaetaparealizarauna
funionperfetamentedenida y elexitodeesta etapa dependera de la laridadon que
la red hayasido denida en el paso 1.
4. Ensamblar el prototipo. La intenionnal de este proyeto, omo yase meniono, es la
onstruiondeunAPI,unainterfazdealtonivelentrelaredylosprogramasdeusuarios.
Las funiones onernientes a omotransmitir bits sobre un anal de omuniaion, lo
ual es implementado a nivel de una apa fsia,queda totalmente fuera del alane de
este proyeto.Nosotros asumimoslaexistenia de failidades de omuniaionfsia.
5 Conlusiones
Las ideas expuestas en este trabajo, se enuadran dentro de un proyetoeduativo del
De-partamento de Informatia de la Faultadde Cienias Fsio,Matematias y Naturales de la
UNSL.
El objetivo general, ontempla el estudio, dise~noe implementaion de una Interfase de
Programas de Apliaion(API) quefailiteel desarrollode apliaiones distribuidas.
Esta herramienta haonstituido un ambito de disusionpermanentepara los doentes que
partiiparon en el proyetoy para todos aquellos que se enuentran dediados a la ense~nanza
que de una u otra maneraesta inueniadapor una plataformade red.
La relevania de esta herramienta es que proveeun medio para onretizar oneptos
ab-stratos, omoes laperformane de un onjunto de servidores ofreiendoserviios.
Considerando que la ense~nanzase imparte a alumnos de arreras de grado, es adeuado
aptar la atenionde los mismos on resultados onretos sobre oneptos teorios. Se la ha
onsideradoomounamanerade lograrelaprendizajesigniativo,inorporandooneptosde
redes, dentro de la estrutura ognitiva delalumno.
Referenias
[1℄ ComerD.E.-InternetworkingwithTCP/IPVolIPriniples,Protools,andArhiteture-Seond
Edition - Prentie Hall- 1991.
[2℄ Comer D. E.- ComputerNetw orksand Internet -Seond Edition- Prentie Hall- 1999.
[3℄ Comer D. E.and Stevens D.L.- Internetw orkingwithTCP/IP - Prentie Hall.
[4℄ Stallings W. - Dataand ComputerCommuniations6a Ediion - Prentie Hall.
[7℄ WilkinsonB.AndAllenM.-ParallelProgrammingTehniquesandAppliationsusingNetwork ed
Workstationsand ParallelComputers - Prentie Hall-1999.
