Computación MATERIA Proyecto de Investigación I

(j

UNIVERSIDAD AUTOlYOMA METROPOLITANA

UNIDAD:

_{I z t a p a l a p a}

’

DIVISION:

Ciencias

Básicas

e Ingeniería

’CARRERA:

Licenciatura

en

Computación

MATERIA

Proyecto de Investigación I

y

Ii

TITULO:

“Protocolos de Comunicación

y

el

Modelo Ciiente/Servidor”

Martes 18/10/1994

’FECHA:

-

’ALUMNO:

Israel Navarro

Ramírez

MATRICULA:

88324809

Proyecto

de

Investigación

I

y

II:

"ProtocdosdeComuMcac

*

i6nyellyodeloc/i~ervMoPs

lsraal

Navarro

Ramírez

...

pues, si

es

que

soy

PREFACE0

Inicialmente este documento estaba destinado a la realizeción y continuación de proyectos de investigación previos comenrados por otros estudiantes Sin

embargo,

durante el

transcurso

de las paradigma ClientdSewidor Aún &o este modelo

no

es

nuevo

N M e , a últimas

fechas

se

ha

potencisdo su impcto en el desarrollo de aplicaciones y en la perspeotiVa comerciai.

Para

poder

investigar

mas

a fondo y cowcer los detalles del modelo fue preciso

modificar

lo parámetros iniciales, sobre la marcha, con los que se empezh este Proyecto

Como se

puede

notru a primera

vista

este es un tema muy dinámico y amplio como poder cubrirlo de manera simple o somera; por lo que el tiempo nunca fue un aliado. La pheación de esta investigación se modifico para cubrir en dos trimestres dos fases fiuidamentales soüCitadas

como

requisitos

La

p h e r a hse consistió en investigación documental con el propósito de

asimilar

todos los aspectos tecnológicos al nivel de conceptos implicados por la tecnología CIienteJServidor y sus modelos de aplicación

La

segunda fase consistió en la investigación de campo necesuia para

realizar

la implantación de

apiicaCiones basadas en el modelo ClientdSeMdor y que pudieran

tena

un uso por parte de la comunidad Los resultados de todas estas investigaciones se sintetiZrm en este documento que consta de dos gmdes partes en

las

que se integm todos los documentos multantes durante el transcurso de dos trimestres, es decir, el Proyecto de Investigaci6n I y Proyecto de Investigación II

investigaciones frente

a

nosotros estaba transcwn ‘emlo toda una revohlcióíl tecnológica asociada al

Para poder lograr _los

objetivos

planteados, primero

era

preciso conocer, a un nivel importante, el

Sistema

Operativo precursor

de

muchos de

los

elementos circundantes al

modelo

ClientdSewidor LJNiX Por lo que &e neCeseri0 considerar una revisión técnica sobre los aspecto

mas importantes

que este Sistema

contiene

en

sus diferentes versiones El primer capituio trata de todos esos aspectos, básicamente sirven para famhmme con el

Sistema

a nivel general

En el capitulo

dos

se pretende plantear los elementos indispensables para que u~llt aplicación o

sistema pueda existir en un ambiente distribuido

La

idea central de este capitulo se obtiene al deducir

que una de las posibles

soluciones

es el paradigma ClientdServidor apoyado por los

mecanismos

de IPC y los protocolos de comunicación

Para el capitulo tercero se va directamente ai estudio de unas de las tecnologías mas exitosas en la

historia de la computación el coyunto de protocolos de comunicación TCPm Se eligió este conjunto de protocolos por que actuaimente conforma el mecanismo de comunicación con computadoras mas u t i l i o en el mundo y se le considera un

estandar

&ef¿to Se debe aclarar que este es un tema enorme

como para poder cubrirlo en un solo documento, pues como es bien sabido, año con afio se publican miles de mvestigacaones, de revisiones, de

cambios,

de conkemas

.

,

etc sobre el tema El enfoque fue la abstracci6n para simpliñcar Es decir, se extrajo aquellos elementos

mas

importantes para el alcance total de los proyectos, principalmente pensando en los contenidos de los _capítulos siguientes

El capitulo quinto se procede a profundizar sobre otra idea importantiskw los mecanismos de

comunicación entre procesos (Z*--plo<rss Cummun*a) El enfoque se realiza principalmente orientado a los aspectos que dos

o

mas procesos en ambientes

UNM

deben

cubrir

para poder comunicarse entre sí, pero io mas importante como transferirse información. También hay que aclarar que este tema es demasiado amplio

como

para poder revisar todos los mecanismos conocidos, así que

solo se revisan

los

aspectos fundamentaes y se pretende ia inducción de los conceptos

En el capitulo quinto se da la

primera

introducción ai modelo ClientdSdor El aicance de este capituio sólo sirve para dar un poco de luz sobre la utüización practica de toda la serie de ideas y conceptos revisados en los capítulos anteriores Este capituio sirve como preparación para el Proyecto de Investigación 11

Para la parte dos del documento el enfoque principai es la implantación de aplicaciones practicas en base a i paradigma ClientdServidor

En esta parte dos del trabajo se presentan todos los elementos técnicos n&os para lograr dicha impiementacion El mecanismo de Ipc elegido fueron los sw&& Este es uno de los mecanismos de IPC existentes

mas

poderosos, no solo por

las vimides inherentes

asociadas

a

la

abstracción de su

diseño sino también ai aprovechamiento pleno del

conjunto

de protocolos TCPKP.

Así

que en el capitulo sexto de este documento se

realiza

una revisión con un buen nivel de detalle sobre todas las particularidades de este IPC

Para cumplir

con

el ciclo,

en

el capitulo séptimo se presentan muchos de los detalles asociados a

la

construcción de aplicaciones ClientdServidor basadas en el modelo de

sockets

Berkeley y sustentados por

una

piataforma UNiX y protocolos de comunicación TPCiiP Si bien actuahnente, existen muchas otras platdo- que sopoitan a los sockets, se eligió esta plataforma debido a que permite la contempiación _seria

de

todos los aspectos necesarios para lograr apiicaciones reales, los ambientes UNIX han demostrado sus capacidades Que los

sockets

existan en diversas plataformas no es otra cosa mas que una demostración profunda de

la

importancia de los protocoios de comunicación

Finalmente, como un complemento a toda la investigación en su conjunto, se lista el código fuente escrito en lenguaje C, una serie de programas que implementan a Clientes y Servidores Estos programas ilustran de manera completa los detalles implicados en

la

implementacion de este modelo

en

la practica

Estos programas esta completos y probados Si bien

es

cierto que son aplicaciones muy sencilias, pero pueden servir como base a desarroüos futuros

Reconocimientos

Durante el transcurso de una

vida

uno se encuentra

con

muchas perronas que van y

vienen

Pero sólo unas cuantas de ellas resultan especiaies en la vida Esas

_personas

especiales tienen un impacto tal que lo marcan a uno pata siempre. Su intluencia

buena

o maia

solo

se

sabe

a paso del tiempo Pero aun son

menos aqu& personas que su influencia positiva te hace lograr el éxito

Debo hscer,

entonces, un profundo agradecimiento a

Victor

Alcaraz Páramo quien con sus asesorias y comentarios me permitmOn ver mas allá de lo evidente lugrando enganchar mi intercS por lo profundo

de las cosas. También, quiero agradecer ai Dr. Solis

Oba

y su estupendo CUJO de Estructuras de Datos, que aunque no lo aprobé, lo que aprendi en éi me servirá para ei resto de mi

vida

profesional

Debo

hacer

mención

que

los comentarios y la perspectiva que Jorge Lonmo tiene, y comparte con sus alumnos,

fue

importante Muencia en mi entedimido del mudo extenor al aula

111 Debo agradecer de

_manera

cumpiida ai M

C

Razo Morales, a

la

M C Solis Mendiola y a la M C

G o d e z Cerezo, pero sobre todo ai

Dr

Eliezer Braun por su contribución ai apoyarme sin merecerlo Nunca se mepentkin

por

ello

Quiero agradecer en general a toda la Universidad Autónoma Metropolitana - Iztapaiapa que me dio

ianto pues me cobijo en sus muros, me consintió en sus

aulas

llenándome de conocimiento y de regocijo

por la grandeza del saber, quiero agradecer a la institución que me hizo madurar como hombre y como persona, quiero agradecer a la institución que pennitió conocer a compaiíeros y amigos que llenaron mi

soledad apoyándome de alguna u otra manera, pero debo reconocer especialmente a Luis Hdberto Martinez y agradecerte donde quiera que te encuentres, a Francisco Souza mi amigo y

Ricardo

García

quienes son personas nobles y capaces, quiero agradecer a la institución que posee un sistema adecuado para la educación autodidacta e inductiva que combate el paternaiismo pero que fomenta la utilización de las mejores capacidades de cada individuo Espero en un tiempo próximo retribuirte todo los que me

has

dado

1

Terminología

y

definiciones

A lo largo del texto se usaran las siguientes convenciones:

1) Las referencias bibliográficas

se

establecen con el siguiente formato general: [AUTOR

-

(ES) tema p # p # r #]

a) Donde AUTOR

-

(ES) es el o los nombre@) de los autores tal y como se da en la bibliogratia

b) tema es el nombre

o

titulo del tema tratado. c) p #

se

refiere al número de página.

d) p #

se

refiere al número de párrafo.

e) r # se refiexe al número de renglón.

Cabe hace notar que los elementos tema y r # son opcionales y pueden no ir en Ias referencias.

También, toda la referencia va en negritas. Ejemplo: [Gonzila

-

Vega

p 8 p 21 separados por un guión.

2) Todos los términos importantes o elementos conceptuales importantes se denotaran por letras en

negritas y cursivas. Ejemplo:

d p & c i p u i .

Y se pondrá en negritas aquellas fi-ases que resulten

importantes, ejemplo: ia arquitectura es el concepto fundameotd a seguir en este testo.

3) Todos las notas al pie de pagina son consideraciones adicionales o comentarios particulares

4) Este documentos hace referencia a ciertos elementos relacionados con la programación en Umx

(utilizando a C como lenguaje) respecto a llamadas al sistema, funciones primitivas, invocaciones,

CONTENIDO

L

Primera

Parte: Proyecto de Investigación I

Capituio primero: El Sistema Opemtivo'ünix ...

1.2. Interfaz con el programador y con el iisuario _..._..._. ...__... ... ._... 1.3. Sistema de archivos

. . .

.

1.1. Principios de diseño ...

..

13.4. Proyección de un descriptor de archivo hacia un inodo _ _ . _ , .__._. .., ... .__...._. .__.._.__.

1.4. Manipulación de arc .<.

1.5. Llamadas al sistema 1.5.1. Descriptor de archivo

1.6. Sistema de EntraddSalida

1.6.1. Entrada y Salida standard ...

1.6.2. Block

buffer

cache .

1.6.3. C-Lists ...

.

. . . ,

. .

. . . , ,

.

. . . , . . .

... <.

. . . ,

. .

. . .

.

. . .

. .

, , . . . , . . . 1.9. Scheduling de CPU ... ... 1.10. Manejo de procesos

.__

__. , .

.

. . .

1.10.1. Process Control Block ..

1.11. Control de procesos . ...

. . . .

. . . ...

.

. . . .

.

..

.

. . .

. .

. . . . ,

. . .

. . . .

.

,

.

. . . . 1.11.1.

s

1.12. Primera

revis

1.12.1.

El

pipe: la primera instancia . . , . . , . 1.12.2. Primera

...

.

... <...<...,...

1.12.2.1. Llamadas ai sistema referentes a los sockets .__. . . .

.

. . . , , . . . . Capitulo segundo: introducción a los sistemas distribuidos .

2.1. Objetivos ... . . , . . . 2.1.1.

_Ventajas

de los s

. . .

.

. . .

. .

. . . .

. . .

. . . .

. .

. . . .

. .

. . .

.

. . .

.

. .

os .... . . .. . . , . . ... . . . ... .. . . ..

.

. . . , . . 2.1.2. Desventajas de los sistemas distribuidos ... 2.2. Comunicación en un sistema distribuido ...

2.2.1. Ideas generales de un Sistema Distribuido

..

._. . . , __.

2.3. Orientación del proyecto respecto de este medko ambiente . . .

. .

. . .

Capitulo tercero: Protocolos de comunieaeiu T C P m . . . . ... 30 3.1. Un vistazo al uso de TCPm .. ... 31

3.2. Clases de direcciones

IP

._____._..._.... ...

3.2.1.LaclaseA _...__.

3.2.2. La clase

B

______.__._.___....__.__ ... 34 3.2.3. La clase C

__...

3.3. Direcciones reservadas

IP

35

3.4. Traducción de las di 35

3.5. Proyección de las direcciones IP a MAC _.._.__.__, ,_. ._.__. . _ . _ _ . _ _ . . _ _ _ _ . ...___._

3.6. Address Resolution Cache ... ... <...<).<._... 36 3.7. Un

_vistazo

ai protocolo de Int .... <...< 37 3.8. . .

IP

. como un . . . .servicio . . .

no

. confiable de entrega . . . .de .paquetes . . . .

. . . . . . . . . . . . . 37

3.9.

L o s

protocolos en la capa de transporte: UDP y TCP

__...

.... - ... 37

38

. . . . , , , . . . ,

.

. . .

. . .

. .

... ... ... < ... < ... <..._...

... < ... .... ... ..

3.9.1. User Datagram Protocol .__. . .

.

._.

. . .

. . .

. . .

. . .

. . ....

. .

. . ...

. .

...

.

.

.

... ... .

Capitulo cuarto: Procesos y Programación . . . . . ,

.

. . . 4.1. Procesos y programas .

4.1.1. Creación de procesos

.

4.1.2. Ejecución de los programas . . . .

.

. . .

.

. . .

... <..._... .... . . . 4.1.3. Control de procesos: fork y wait .__.__... .__..._._..._. ... ... ... ... .

4.1.3.1. La llamada al sistema wait ... 4.1.3.2. Zombies ... 4.1.4. Terminación de procesos

4.2. W S de bajo nivel y Descripto

4.3. Aspectos bksicos sobre la implantación de la comunicación entre procesos ..._.__... . 4.3.1. Seiíaies e interrupciones . ... . . . , . . .

.

. . . ,

.

. . . 4.3.2. Manejo de eventos ...

4.3.3. Sincronización de procesos y tiempos fuera ...

Capitulo quinto: Modelo ClienteScrvidor ._ .<.. 5.1. Direccionamiento .

5.2. Modelo de comunicación entre procesos

5.3. Comentarios sobre el Modelo Cliente

-

Servidor y las llamadas al sistema de los

. . .

.

, , . . . , . . .

.

. . .

. .

. . .

.

. . .

.

. . .

sockets . .

.

, ,

.

. . .

. . .

. .

__.

. .

. . .

. . .

. . .

. . .

. . .

.

. .

. .

. . .

. .

. . .

. . .

. . . .

. . .

. . .

. . .

.

.

. .

.. .

. . .

. .

. . .

. . .

.

.

. . .

. . .

. . .

.

5.3.1. Primitivas de bloqueo contra de no bloqueo .. ._. . . .

. .

. . ... . . .... . . . ..._ _..._. .... ._.

.

.. . 5.3.2. Primitivas almacenadas en buft'er contra no almacenadas

5.4. Implantación del modelo Cíiente-Servidor utiiizando la abstracción de los sockets.

5.4.1. Sockets

..

. . .

. . .

. . . .

. . .

. . .

.

.

. .

. . .

. . .

. . . . . . . . , . . . .

.

5.4.1.1. Manej los

.

. . .

.

. . .

.

.

.

5.4.1.2. Estructuras de datos para los sockets _.__.__.._. ._. ._..__.__.._. ._._. . ._. ...__. ...._. .., ._. ._ 5.4.1.3. Direcciones para

5.4.1.4. Actualización de Conexión __.._.._..._.._ 5.4.1.5. Derechos de Acceso

5.4.2. Usando los Sockets

IL Segunda Parte: Proyecto de Investigación It

Capitulo sexto: Modelo ClientdServidor y las prop 6.1. Propiedades de un ClientelServidor y los IPC . . . .

6.2. Los sockets

como

IPC ...

6.2.1. Características de los sockets ... 6.2.1.1. ¿Qué es un socket? __.... . _ _ . _ _ . _ . ... .__.__.... ... ._....

.

._._..._... ... 6.2.1.2. Dominio de un socket ._.._. ... < * ... <...<... 6.2.13. Propiedades de la comunicación y el Tipos de un socket ._... ... ... 6.2.1.4. Tipos disponibles de sockets

6.2.2. Primitivas relativas a los sockets

6.2.2.1. Creacton de un socket _._...._..

6.2.2.2. Enlazamiento del socket a una duección ...

.,

6.2.3. Comunicación. . . . , . . .

6.2.3.1.2. Primitivas asociadas a este

modo

de comunicación ... 6.2.3.2.

La

comunicación usando Flujos de Datos (Streams) ...

6.2.3.2.1. Principio general . .

. . .

. . .

.

. . .

. .

. . .

.

I .

.

. . . , .

.

.

.

. . . .

. .

.

.

. . .

. .

. . .

.

. . . ,

.

. . . . I

. .

60 60 61 62 62 62 63 64 64 65 66 66 67 67 67 68 69 69

Capitulo séptimo: Implementación

dd

Modeio

ClientdServidor . . 7.1. imphta&n de aplicaciones en el dominio Internet

7.2. Características de implementacion una aplicación clientelsemidor bajo el dominio Internet con el tipo de socket SOCK-DGRAM en

modo

no conectado . .

7.2.1. Construcción de un servidor _. ._. ... , _ _ . _ . ._..__. ._. ,..__.__...__. .... ._.__,.__._. .., ._. .

.,

7.2.1.1. Creacion de un socket ... 74

7.2.1.2. Espera y recepción de la 76 7.2.1.3. Preparación y envio de la respuesta _.._._ 76 7.2.2. Construcción de un cliente . ... <... 77

Anexo: Programas fuente de aplicación de conceptos

.

, . ... 79

Programa 1. ..._... <._... 79

Programa 2. ... 82

Programa 3. ... 85

Programa 4. ... 87

94 Programa 5. ... 90

Capítulo primero El Sistema Operativo Unix

Setiales Manejo de terminales

Sistema de Caraderes

de Us

Manejadores de Terminal 1.1. Principios de diseño

Sistema de Archivos

Scheduling de C W

Demonio de Paginación

M P P i n g

sistema de Bloques de U S

-*ljkpdms .' de Memoria Virtual

Unix fue disekdo para ser un sistema de tiempo compartido La interfaz standard para el usuario, denominada

W ,

es simple y puede ser remplazada por otra si se desea El sistema de archivos

es

un

árbol multinivel que permite a los usuarios crear sus propios subdirectonos. Todos los archivos de datos de los usuarios son simplemente secuencias

de

bytes. Los archivos en disco así como los dispositivos de Entrada/Salida' son tratados similarmente mientras

sea

posible. Entonces, las dependencias debidas a los

diipositivos, _sus manejadores y sus particularidades se mantienen dentro del núcleo del sistema

operativo también conocido como h e l

Las

únicas

entidades activas

en

Unix son los procesos, los cuales son muy similares a los clásicos procesos secuencililes Cada proceso ejecuta un

solo

programa y tiene un único hilo de control,

es

decir, tiene un contador de programa, el cual mantiene un registro de la siguiente instrucción por ejecutar

Contmladoras de terminal

Teminales

~ . . . . ~ ~ . . . . ~ ~ ~ ~ . . . ~ ~ - ~ . . . ~ ~ ~ ~ . . .

El

usuario

Comandos y tipos de shell

Compiladores e Interpretes

Librerías del sistema

Controladores de Controladores de

Dispositivos memoria

Memoria

~ ~ ~ . . . ~ ~ ~ ~ . . . ~ - ~ ~ ~ . . . ~ ~ - ~ . . . ~ ~ ~ ~ , . . ~ ~ ~ . ~ . ~ ~ . . . ~ ~ ~ . ~ . ~ ~ . . . . ~ ~ . . . ~ ~ ~ . . ~ ~ ~ ~

Dispositivos de almacenamiento

IntMaz de llamadas al sistema para el kernel

Unix soporta la operación mnitiproeeso. Unir. es un sistema de multiprogriimación. Por lo que se pueden ejecutar varios procesos independientes ai mismo tiempo y un proceso puede fácilmente crear nuevos procesos. Cada usuario puede tener varios procesos activos a la vez.

De

hecho,

en

la

mayoría de las estaciones de trabajo con un solo usuario, se ejecuian varios procesee en segundo piano o de forma wíncrona, U d o s

demonid,

a m cuando el usuario se encuentre ausente.

Los demonios se inician de manera automática cuando se arranca el sistema. Un demonio típico es el

danonio cron que “despierta” una vez que se cumple cierto intervalo de tiempo para verificar si existe

trabajo para él. Si lo hay, lo realiza. Después “duerme” hasta que es tiempo de la siguiente verificación. Este demonio es necesario, puesto que en Unk es posible planificar actividades con penodos de

anticipación. El demonio cron también se utiliza para iniciar actividades periódicas. Otros demonios controlan la llegada y salida del correo electrónico:, la cola de impresión, verifican si existe en memoria el número suficiente de paginas, etc.

Los demonios tienen una implantación directa en UNX, puesto que cada proceso es independiente de los demás.

La pianeación de proceso^ en ejecución o Scfreduíin~ es un aigoritmo simple de asignación de prioridades. El manejo de memoria es un algoritmo de región variable con intercambio o Swqpping. En la versión 4.3BSD4 usa un algoritmo de demanda de paginas como un meCaNsm0 para soportax el manejo de memoria y las decisiones de scheduling de CPU.

En donde otros sistemas tienen elaborados aigoritmos para operar con situaciones patológicas, Unix lo hace mediante un mecanismo controlado de choque llamado “pánico”.

Así,

en lugar de intentar remediar “curando” dichas situaciones, Unix trata de prevenirlas. Unix se basa en

la

idea de simplificar y reducir ai mínimo el esfuerzo.

Unix consiste de dos partes separables: el núcleo o kernel (palabra del alemiin que sipfica núcleo de o corazón) y los programas del sistema. Unix puede verse como un sistema estratiíicado o de capas.

Todo

Io que se encuentra de bajo de la Urtkfaz de las lE8niti8as al sistema y sobre el hardware es el kernel. El kernel proporciona el sistema de archivos, el scheduling de CPU, el manejo de memoria y de otras funciones del sistema operativo hacia las Uamadas al sistema. Los programas del sistema usan las llamadas al sistema soportadas para suministrar fiinciones de gran

utilidad,

tales

como

compilación y

manejo de archivos.

Las

llamadas al sistema, por lo tanto, definen la interfaz d d programador en

Unix.

El conjunto

de los programas

del

sistema define el contexto que d kernd debe saportar.

Las

llamadas al sistema pueden ser agrupadas dentro de tres categonas: manipulación de archivos, control de procesos y manipuiición de información. Debido a que los dispositivos son tratados como archivos (especiales) las mismas llamadas al sistema deben soportar ambos tipos de objetos y debe ser

transparente en primera instancia, por lo que se puede considerar que es necesario otro tipo nuevo o adicional de llamadas al sistema con una categoría especial.

En la literatura no es sencillo encontrar el por que le airibuyeron este nombre a este tip0 de pmgranias especiales. Se emibeenespeaoi &mmioanno traducnón liierui de iIcssor un termino muy wmúnen la litenmira y “jerga” de üNE.

El iennino denotaQpor lapatabradeduhgesmuy diRIil detradnoIsin auks &cir muchaspalabras. En general y de manera muy sencilla se pede decir que este termin0 se usa para &notar una &e de programas y regias de gestión

apíicabia a los procesos en ejecución de tal forma que se appwechen los recursa~ en io mas posible. Wra eviíar

compiicaciones se usara esta palabra en ingles.

BSD son las sigias

a

para denaar las versiones de UNIX CMlCebtdas ’ en la universidad de California en

3

1.2. iaterfaz con

d

progrini.dor y con el usuario

Tanto el usuario como el programador en un sistema Unix principalmente inieraccionan con un conjunto de programas dispombies suministrados.

Estos

programas se encargan de

realizar

las Uamadas

necesarias al sistema para soportar sus iünciones, pero las

llamadas

como tales están contenidas dentro

de los programas y

no

resultan obvias para el usuario común. Con ello se logra que el usuario perciba

una apariencia monolítica y virtual (tal y como se teclean los comandos por el usuario así se ejecutan).

Si

embargo, tanto los programas escritos por el usuario y, como casi todos, los programas del sistema, normalmente se ejecutan por un interprete de comandos. El interprete de comandos en Unix es un proceso del usuario como cualquier otro que éste establezca durante su Sesión

(mas

adeiante se

explica esto desde el punto de vista de procesos). Al interprete de comandos se le denomina shell pues esta

alrededor

del núcleo del sistema operativo.

Los usuarios pueden escribir su propio

shell.

Existen muchos y muy variados. Algunos de los

mas

conocidos y utilizados por ser suministrados con casi todas las versiones de

Unix

son: Bourne shell (escrito por Steve

Bourne,

que es el mayormente usado o suministrado), C shell (debido casi por completo a Bill Joy) y el Kom shell (escrito por Dave Korn, muy popular actualmente ente los programadores).

Por

compatibilidad con las otras versiones, cualquiera de estos shell comparten la mayoria de los elementos del lenguaje en cuanto a su sintaxis.

Además, todos ellos son también lenguajes de programación con variables e instrucciones de control, condic¡onales y de iteración tal y como las tienen los lenguajes de alto nivel. También pueden ejecutarse archivos que contienen comandos del shell como si fuera otro comando

mas

y a estos archivos de comandos se

les

denomina Stid script.

La

ejecución de un comando, entonces, puede verse como una

llamada a una subrutina.

L a programación del shell resuita un instrumento de gran poder con la que se pueden construir apüuciones muy sofistieidas sin necesidad de programar en ningún lenguaje de alto nivel convencional

Esta

f i h i i a

es

uno de los grandes aportes de Unir a

los

sistemas operativos.

Aparte del sheli,

la

interfaz con el usuario consta también de un gran número de programas y una vasta serie de utilerias standard Se pueden dividir, en general, en las siguientes categorías

1 Comandos para el manejo de archivos y directorios

2 Filtros

3 Compiladores y herramientas para el desarrollo de programas

4 Procesamientodetexto

5 Administración del sistema

1.3. Sistema de archivos

1.3.1. Bloquea y fragmentos

La mayor parte del sistema de archivos esta basado en la estructura de bloques de datos que contienen todo lo que se guarda en los archivos. El tamaño de un bloque y un í?agmento se definen

durante la creación del sistema de archivos de acuerdo con los propósitos de

uso

para este sistema: si se sabe de antemano que habrá muchos archivos pequeños entonces el tamaño del fragmento debe ser también pequeño; si habrá repetidas transferencias de archivos grandes entonces el bloque básico deberá

ser grande.

Ipblp.d.plEhiyg. b b l p d e b ~ I * b d . ~ m * O n

parr) d*-

Espacio del sistema Espacio del

usuario

lista dc inodoa

Espacio del disco

Detalles de implementación obligan a que el mimimo radio entre bloque y fragmento sea de 8: 1 y el mínimo tamaño de bloque sea de 4K así que elecciones tipicas son 4096512 para el caso de formación y para el mas reciente de 8192:1024 K. Los

sectores

en disco son usualmente de 512 bytes. Un bloque

mas

grande que los 512 bytes es deseable por cuestiones de rapidez.

inodos

super

m b s q u e Bloques de datos

lllll~~llllllllll

I I

I

I

I I

Figura 3. Organización del disco en lor sistemas irdicionsk. de Unix

Como usualmente en casi todos los sistemas Unk contienen archivos de tamaño pequeño, bloques demasiado grandes causarían

una

gran fkagmentación interna. Por

lo

tanto las diversas versiones de

Unk

establecen cotas respecto a los tamaños de bloques y fragmentos en base a las políticas de administración.

Por

ejemplo en 4.lBSD se limitaba el bloque a 1024 bytes ó 1 KB. La solución en 4.2BSD es usar dos tamaños de bloques: todos los bloques de un archivo son bloques de gran tamaño (de

_SKB),

excepto el último.

E

l

último bloque es de un tamaño apropiado a un múltiplo del fragmento mas pequeño.

1.3.2. inodos

5

La información mas importante son los identificadores de grupo del archivo, los _Últimos accesos, las

fechas de ultima modificación, el número de ligas duras y el tipo de archivo (directorio, iiga simbólica, dispositivo de caracteres, dispositivo de bloques, archivo puro o socket).

Tabla de descnptores de

archivo del proceso padre

descnpiores de archivo del proceso hijo

Tabla de descnpiores de

archivo de los procesos no relacionados

¡nodo

_____IJ\

I

Contadorde

I

ligaduras

1

I

I

uid

Apuntadores a los bloques en disco

Además, el inodo contiene 15 apuntadores a bloques de disco que contienen la información del archivo

L o s

primeros 12, apuntan a las direcciones de los bloques que contienen la información en sí del archivo y a los cuales se les denomina como bkques directos. Así, para archivos pequeños (no mas de 12 bloques) las referencias son casi inmediatas puesto que una copia del

inodo

se mantiene en memoria

principai rmentras el archivo esta abierto. Si el tamaño del bloque es de 4

KB

y hasta de un poco mas de 48 KE3 de datos, entonces pueden accederse directamente por su inodo. Los restantes 3 apuntadores, referencían a los bloques indirectos que son bloques que contienen direcciones que

hacen

referencia a

bloques directos Si el archivo es muy largo para

usar

bloques indirectos, entonces los tamaños de los

fkagmentos de datos se aplican solo a los bloques. Esto es, el primer apuntador a un bloque indirecto o

bloque indirecto simple (que es un arreglo de índices que contienen las direcciones de bloques que si

contienen datos) pueden seguir creciendo con bloques doblemente indirectos y hasta bloques triplemente

indirectos

para controlar la operación de entradalsalida necesaria. Una vez que el

inodo

es localizado, se realiza la

llamada a la primitiva open y se establece

una

referencia a la estructura de archivo en el kernel mediante

el descriptor de archivo. (Para mayor claridad ver la parte del sistema de entraddsalida y la sección de proyección del nombre de archivo a un M o mas abajo).

1.3.3. Dueetorios

No hay distinción alguna entre archivos puros y los directorios en el nivel

mas

simple de

implementación, los contenidos de un directorio se mantienen en bloques de datos y los directorios como taies están representados por sus inodos como un archivo común solamente cambiando en el campo del inodo que especifica el tipo de archivo En los archivos comunes o puros se asume que no contienen ninguna estructura a diferencia de los directorios Por ejemplo, en la Versión 7, los nombres de archivo estaban Iunit&tEos

_a

₁₄

caracteres

así

que los duectoiios

eran

listas de entradas de

16

bytes 2 bytes para un número de inodo y los

14

para el nombre del archivo En 4 ZBSD los archivos son de longitud variable de hasta 255 bytes así que las entradas en los directorios son de longitud variable Cada entrada contiene la longitud del archivo, el nombre del archivo y el número de ¡nodo Las rutinas de manejo y de busqueda de archivos se vuelven complejas debido a este esquema de longitud variable Pero, proporcionan ai usuario facilidades en cuanto ai manejo de sus archivos ai poder seleccionar nombres compietos para

especitíCar

su significado con pocas restricciones de espacio Esta idea es útil

cuando los usuarios conviven dentro de un grupo de desarrollo o donde se necesite que diversos usuarios utilicen los mismos archivos

Además,

de entrada, en un directorio siempre se encuentran los primeros nombres

"."

que hace

referencia ai directorio actual y 'I.." ai dKectorio anterior en la jerarquía, Uamado como "padre"

Las

nuevas entradas se agregan en la primera

zona

con espacio disponible generalmente a l final de los que ya existen Las búsquedas se r d i lineaimente

1.3.4. hyección de un descriptor de archivo hacia un ¡nodo

L o s usuarios se refieren a sus archivos mediante su ruta de iceeso mientras que d sistema de archivos usa los ¡nodos como su definición de archivo. El kernel debe realizar una transformación para pasar del path name del usuario ai inodo correspondiente. Los directorios son la primera herramienta para realizar esta transformación. Las Uamadas referentes a los archivos abiertos pasan como argumento el descriptor de archivo. El descriptor es usado por el keme.1 para construir un índice

llave a la tabla de archivos abiertos por los procesos actuales. Cada entrada en la tabla contiene un apuntador a la estructura de archivo que a su vez apunta al inodo en turno. La estructura del inodo apuntada por la estructura de archivo es un copia con información adicional (contador de cuantas estructuras de archivos lo apuntan, etc.) respecto del inodo en el disco.

1.4. Manipulación de archivos

7

ésto, queda como responsabilidad del programador asignar la estructura

al

archivo que e1 elija y seguir al pie de la letra las convenciones que tome sobre la información en sus archivos.

...

Los

archivos se protegen mediante los bits de derechos. Que son UM cadena de diez bits donde el

primero indica si se tata de

un

directorio o de otro tipo de archivo, los tres siguientes refieren al acceso

del propietario. _Los siguientes tres se refieren a los derechos de acceso de los demás usuarios del gnipo

Los últimos tres controlan los accesos de las demás

personas.

Cada tercia de bits tiene el propósito

de controlar la lectura, escritura y ejecución (o búsqueda) del archivo, respectivamente.

Los archivos se organizan en directorios con una estructura arborecente recursiva. Los directorios son en si mismos archivos que contienen información de como encontrar los archivos que él referencia. Una ruta de acceso o path nume para un archivo es una cadena de texto que lo identifica mediante la trayectoria a seguir, a través de la jerarquía definida por el

árbol,

para poder alcanzarlo.

UNx mantiene dos tipos de rutas de acceso a un archivo: rutas absolutm (absolute path unmes) y rutas &tivas (dative path names). Las rutas absolutas inician en la raiz del sistema de archivos y se

distinguen por el carácter "/" al inicio de la ruta.

Las

rutas relativas inician en el directorio actual, el cual

es

un atributo del proceso que accede a la ruta. Un archivo puede

ser

conocido

por

mas de un

nombre y por mas de un directorio. Tales casos son conocidos como ligas (iinks) las cuales son todas tratadas igual por el Sistema operativo.

La versión 4.3BSD también soporta ligas simbólicas que son archivos que contienen la ruta absoluta de otro archivo. Una liga simbólica puede

ser

de dos clases particulares: ügus ukurcrs ( l i d finks) y ligas

flenMRs

(soft Iimks). Las ligas flexibles (no como las duras) apuntan a los directorios así como a las referencias cruzadas de fiontera de un archivo. Una liga dura sólo apunta a un directorio especifico. Por ejemplo,

"."

refiere exclusivamente al directorio mismo y

".."

se refiere al directorio padre'.

Los dispositivos de hardware tienen asociados nombres de archivos en el sistema de archivos. Los archivos

especiales

de dispositivos o simplemente archivos especiales son conocidos por el kernel

como las interfaces de los dispositivos en sí, pero existen pocas restricciones en general para que los usuarios puedan acceder a estos archivos como si fuera cualquier otro archivo. La razón

es

que para Unix todo es un archivo.

poseedor.

1.5. Llamadas al sistema asociadas a la manipulación de archivos

Las llamadas

al sistema para una manipulación básica de archivos

son:

create, open, read, write, close, unlink y trunc. La llamada al sistema create, dada una ruta de acceso, crea un

archivo vacío o trunca uno existente.

Un archivo existente es abierto mediante la primitiva open la cual toma la ruta de acceso y el modo

de apertura (leer, escribir o leedescribir) y retoma un entero pequeño denominado descriptor de archivo. Un descriptor de archivo debe pasarse también a las primitivas read y write así como la

dirección del buffer y el número de bytes a transferir para poder

realizar

el paso de datos desde o para un archivo dado

Por

otro lado, un archivo

es

m a d o hasta que se pasa su descriptor de archivo a la llamada de sistema close. La Uamada al sistema trunc reduce a cero

bytes

el tamaflo de un archivo.

Es usual considerar que uaa estnictura arboreceníe pcede ser tratada como una especie de árbol gedó@co en donde

por nivel. M, la raiz del árbol es el ancesm> de todo nodo interno. El "padre" es aquel nodo que tiene

porotmnodomas

hay-

nodos asociaQs a él pero en niveles mas internos, así los hijos son los nodos iniem referenciados

arriba en la jerarquía.

5

9 1.5.1. Descriptor de archivo

El descriptor de archivo es una entidad de gran importancia en la manipulación de archivos. El descriptor en si

es

un índice dentro de una pequeña tabla que mantiene información relativa a los

archivos ab-os por un proceso. Los descriptores inician su secuencia en O y en raras ocasiones

llegan

a ser de mas de 6 ó 7 para programas típicos, dependiendo del m8xúno número de archivos

abiertos simultáneamente.

Cada operación read ó write actualiza un contador de desplazamiento dentro del archivo, el cual

esta asociado con la entrada en la tabla de archivos descrita antes, y que

es

usado para determinar la posición

en

el archivo para la próxima operación. En relación a ésto, existe la llamada al sistema 1 seek

que permite que la posición en el archivo sea establecida explícitamente.

Las

llamadas

dup y dup2 se usan para obtener un nuevo descriptor de archivo que es un copia exacta del existente. La llamada

fcntl permite examinar y asignar valores a varios parámetros de un archivo abierto. La Llamada

ioctl permite manipular los parámetros de los dispositivos.

La

información propia del archivo (como es su tamaño, modos de protección, propietario, etc.) se

obtienen de la llamada al sistema stat. Existen entonces, diversas llamadas al sistema que permiten

modificar porciones de información asociadas con un archivo. A su veq esas diversas llamadas tienen

variantes que se pueden aplicar a los archivos así como también a sus dedptores.

Manejedor de los dispositivos de bloques 1.6. Sistema de EntmddSalida

Manejador de los dispositivos de caracteres

Uno de los propósitos mas importantes de un sistema operativo es el de librar al usuario de las

peculiaridades del hardware. Como se menciono antes, el sistema de archivos presenta una visión simple

y consistente de almacenami ento

en

porciones plenamente identificadas como es un archivo, siempre por

encima del hardware. De hecho, en Unix, Ins eancteristius del hardware permanecen ocuttris de in mayor parte del kernel mismo6 por el Sistema de EntradaíSaiida.

I

lnterfaz de llamadas al sistema para el kernel

I

Plain file

Sistema de interface

discipline

lnterfaz

para

ambientes red

I

El Hardware

I

Esta es una de las ContriWoues mas notabla respacto al enfoque de diseño y a i nivel de absimxión que Unix hace a los

Sistemas Operativos maiemos. De hecho muy diferenies S iO p m t ~ ~ actuales utilizan y expican estas ideas no Sóloparael sisiemade Archivossinoparaotrasentidades fiincionalas. Ver [Cusierl en&& se realiza una &scripcih detallada del Sistema operativo Windows NT.

El sistema de entradaísalida consiste de un sistema de buffers en memoria cache, código de manejadores de dispositivos de propósito general y manejadores para hardware especifico. Por lo tanto, son solo los manejadores de los dispositivos los que se ocupan de cubrir los requerimientos que el dispositivo particular necesite para su funcionamiento.

Uno

de los sistemas de entradalsalida mas representativos es el de la versión 4.3BSD que en seguida se describe. Existen tres clases de entidades que pueden

realizar

operaciones de entradalsalida: dispositivos de bioques, dispositivos de caracteres y la interfaz de socketa.

Espacio del

I

usuario

Núdeo

___

raw interface

tty

Operaciones sobre cooked interface

archivos

ttY

I t

t 1 t

Sistema de Archivos

BuWer cache

&

Manejadores de disco

line discipline

I I

Manejadores de terminal

Fbum 7. El tbtwna de Us gm&koen Unix

Dentro de los dispositivos de bloques se encuentran las cintas _magnéticas y los discos magnéticos. SU

uracterbtica distintiva es que pueden aer directamente direccionabka en bloques de tamriio

pruietermmido, usualmente 512 bytes. Un manejador especifico para este dispositivo es requerido para aislar ai kernel sobre los detalles particulares como por ejemplo: desplazamientos de la cabeza

lectora, de los platos, tracks, cilindros, etc. Estos dispositivos pueden accederse a través de SU

11

recomendable para programadores inexpertos) que sean accedidos indirectamente por el sistema de archivos. De cualquier manera, las transferencias son almacenadas en un buffer dentro de la memoria cache lo que se refleja de manera importmte en la eficiencia del sistema.

Los dispositivos de caracteres incluyen las terminales con monitor, la impresora de línea y cualquier otro dispositivo que no use bloques

con

cache buffers excepto, claro,

las

interfaces con

las

redes. Aunque, algunos de estos dispositivos requieren de almacenamiento temporal debido a las diferencias en

las

velocidades de transferencia y de algunos archivos especiales, son tratados siempre como dispositivos orientados a terminal o como terminales.

Su

almacenamiento temporal se implanta mediante

GI&

(mas adelante se discutirá brevemente lo que son los

C-lists).

Los manejadores de dispositivos

son

encontrados en uno de dos arreglos, cada uno con la

información referente a los dispositivos de bloques y de caracteres respectivamente. Para poder determinar en cual arredo buscar, un dkpositko se distingue por su clase y por un numero. El

número consiste de dos partes: major &vice number que se usa como índice para encontrar en dispositivo apropiado en el arreglo d e t e d a d o por la clase y el miam hvice number, que interpretado por el manejador ya encontrado, permite identificar exactamente

_las

propiedades del hardware.

Por lo anterior, el manejador de un dispositivo se conecta con el resto del kernel solamente por las entradas en el arreglo de la clase que él pertenezca y por el uso común de los sistemas de almacenamiento temporal.

Debe saltar a la vista que este tipo de segregación es importante por cuestiones de portabiidad y de

configuración del sistema respecto a la integración

como

un todo. Esta idea es otra mas de las innovaciones en un sistema operativo por parte de U n k

1.6.1. Entrada y Sdkia standard

Los procesos pueden abrir archivos como lo requieran, pero siempre se tienen tres descriptores de archivo, con valores de descriptor iguales a O,

1

y 2. Estos valores están dados por el sistema desde el inicio de cada sesión. Se conocen como: O para entrada standard, 1 para salida standard y 2 para el error standard.

Todos

los shells permiten tratar esos descriptores como archivos utilizando instmcciones de

sintaxis muy simple. A esto se le llama redinccianatniento de e n W s a i i d a .

1.6.2. Block Buffer Cache

Es importante entrar en un poco

mas

de detalle en cuanto a los dispositivos de bloques y al manejo

en

memoria que se hace en cuanto a sus transferencias, puesto que estos dispositivos, sobre todo los

discos, son los medios de almacenamiento secundano mas usados actualmente. Los dispositivos de bloques usan buffers de b i u q ~ en memoria cache

(Mock

buff¿r

cache) como ya se menciona arriba.

E

l

block buffer cache consiste de un cierto número de encabezados de buffer cada uno de los cuales apunta a una porción de memoria así como de un número de dispositivo.

L o s

encabezados de buffer se

mantienen en varias listas ligadas, cada una con los siguientes propósitos:

La información que nunca sale, tales como los super bloques del sistema de archivos

Buffers vacíos que no tengan asociados ningún bloque en disco o en memoria.

L o s

buffers en esas listas, por eficiencia en la búsqueda, se mantienen referenciados por medio del

hashing con llaves como el número de bloque y de dispositivo.

Cuando un bloque se busca por un dispositivo (esto es, una lectura) se hace una búsqueda en

memoria cache. Si se encuentra al bloque, éste se usa y no hay transferencia de entradalsalida. Si no se encontró, se escoge un buffer de la lista de vacíos, el número de dispositivo y de bloque asociado a él se

actualii se asigna memoria y se transfieren los datos desde el dispositivo. Si no hay buffers vacíos,

implica que el buffer de

LRU

esta escribiendo hacia un dispositivo y el buffer se vuelve a utilizar.

Una

observación debe hacerse con la cintas magnéticas, estos dispositivos

requieren

que los bloques

sean escritos en cierto orden (que depende de las caractm’sticas del formateado) por lo que también

deben proporcionarse facilidades para escrituras sincronas desde los buffers.

Los

bloques de directorios

también deben cumplir con esto.

Ahora en el caso de una escritura, sí el bloque en cuestión está listo en el buffer cache, los nuevos

datos se ponen en el buffer, sobre escribiendo lo que hubiera, el encabezado del buf€er se marca para

indicar que el buffer se ha modificado siendo

no

necesaria transferencia de entraddsaiida.

Para tener un control fino y evitar inconsistencias en los datos se

realizan

revisiones periódicas de bloques de buffers ”sucios” (dirty bflm)’, con esto se reducen los problemas ante posibles caídas del sistema.

El número de datos en un buffer crece conforme los procesos de usuario escriben mas datos de los

que ya se encuentren

en

él. Cuando esto pasa, un nuevo bufFer

lo

suficientemente grande para retener

todos los nuevos datos se dispone, y del buffer original

se

copian

los datos antexiores seguidos de los nuevos. En el otro caso, el buffer se contrae, un buffer se toma de la lista de vacíos (esta lista

es

generalmente una cola), las paginas de exceso se e.scriben en él y se escribe actualizando en el disco.

Finalmente, el tamaño de los buffers cache pueden tener un profundo impacto en el desempeño del sistema, puesto que, si son lo suficientemente grandes, el porcentaje de accesos a memoria cache se

dispara pero el número de transferencias de entraddsalida se vuelve bajo. Hay también una &e de

interacciones interesantes con respecto a los buffers cache, el sistema de archivos y los manejadores de dispositivos. Cuando se escriben datos a un archivo en disco, estos datos son almacenados temporalmente en cache y el manejador del disco ordena su cola de dida de acuerdo con la dirección

del disco. Esas dos cosas permiten al manejador del disco minimizar las búsquedas de las cabezas del disco y escribir datos optimando el tiempo en rotaciones de los platos.

Cuando

se

leen datos del disco, el sistema hace una a c c h de lectura

aáelontada

(red-ahepd) de un bloque.

Así

que la lectura esta

mas

cerca de ser asínorona que una escritura.

Por

io que se puede

concluir, que la salida a disco (a través del sistema de archivos)

es

mas rápida que SU entrada, para

grandes transferencias, de acuerdo con la intuición.

1.6.3. C-Lists

Los manejadores de terminales usan sistemas de buffers orientados a caracteres. Estos sistemas

involucran el mantener pequeños bloques de camaeres (usuaimente de 28 bytes) en listas ligadas. Se

proporcionan rutinas para encolar y desencolar caracteres de tdes listas.

Todos

los bders libres de caracteres se mantienen en una lista simple de libres, por lo que el número de manejadores de terminales

que se estén usando l i t a n el número de caracteres que se estén agregando en un momento dado para

Esto se refiere a que un buffer ya haya sida utüiza& y exisie i n i d ó u pero que m es útil para este caso.

13

cierta terminai. Una llamada al sistema de escritura agrega caracteres a la lista para el dispositivo. Una transferencia inicial es arrancada y la interrupción

causa

que se quiten los caracteres. Una entrada es

pues similar a

una

interrupción.

Las terminales típicamente soportan dos tipos de colas de entradas; la conversión de la primera cola (llamada rmy queue) a la otra cola (llamada caiioriical queue) es realizada de inmediato por una rutina

de interrupción puesta al final de la línea de caracteres. El proceso que

hace

la lectura en el dispositivo es invocada ahora y los caracteres en la "lista canónica" están disponibles para retomarse al procesos de usuario.

Es

posible tener los caracteres directamente del manejador del dispositivo (sin pasar la lista canónica) por medio de la raw queue. A esto se le llama row niode.

Los editores de texto orientados al uso de pantalla completa que necesitan reaccionar inmediatamente a lo que se teclee, usan el raw mode. Un esquema que resume en q a figura todo lo que se discutió en esta sección se muestra en una pagina anexa en la figura número 5 .

1.7. Manejo de memoria

Muchos de los primeros sistemas Unix se desarrollaron en mini computadoras PDP-I

1

que tenían solamente 8 segmentos en su espacio virtual de direcciones y cada uno de los cuales era de 8192 bytes. Después se implanto en grandes equipos como la PDP 11/70 que permitían instrucciones separadas y espacios de direcciones, sin embargo seguía siendo un problema el espacio en memoria, por lo que el kernel estaba severamente limitado. Por lo tanto, los recursos

en

memoria eran sumamente insuficientes como para justificar y soportar un manejo sofisticado de memoria.

Así,

Unix cuenta con algoritmos

óptimos principalmente para preservar espacio; toda la imagen de memoria estaba en intercambio constante en disco.

Los Sistemas antes de la versión 3BSD de Unix usan exclusivamente el intercambio para manejar la contención en memoria entre procesos: si hay mucha contención, los procesos son intercambiados fuera de memoria principal hasta que haya suficiente disponible. También, si hay procesos grandes obligan a

los menores a salir y procesos mas grandes que la memoria principal ocupada por el kernel no son comidos del todo. El segmento de datos del sistema y el del _usuario se mantienen en memoria contigüa a la memoria principal por eficiencia en la transferencia con el intercambio. Sin embargo, existe el serio problema de la fragmentación externa de memoria.

A continuación se

da

UM breve descripción de la forma en que muchos sistemas Unix hacen el swujping o

_htercamhio

La asignación del espacio para los procesos

en

memoria principal y de intercambio se hace mediante la idea del "primero que cabe" Cuando la imagen de memria del proceso se incrementa (ya sea por una expansión

en

segmento de pila o de datos o en ambos) una nueva parte de memoria libre suficientemente grande para la nueva imagen es alojada

La

imagen de memoria principal

se copia y la imagen vieja se libera con la actualizaci ' 'ón de las tablas apropiadas

En

caso de que no haya

suficiente memoria el proceso se intercambia &era y será regresado hasta que haya un pedazo de memoria con el tamaño suficiente para contenerlo

Por

lo discutido

en

la sección de manejo de procesos en este mismo texto, se tiene que no hay necesidad de intercambiar el segmento de texto pues este puede compartirse y _además es de solo lectura Esta es una de las razones principales de que el segmento de

texto sea de solo lectura se refleja en un menor trafico de intercambios para el sistema

Las

decisiones

de que proceso deberá

ser

intercambmdo son tomadas por UM parte del scheduler, llamada precisamente

principal, es

muy

grande y en casos en los que no haya un candidato evidente con los criterios anteriores entonces se escogen por su edad, los

mw

viejos no usados.

Existen mecanismos para evitar el thrushkg (este termino tiene diversas acepciones a io largo de la bibliograiia, algunos se reñeren a él respecto a ciertas condiciones anómalas y otros lo definen como condiciones que no deben presentarse) básicamente no dejando que un proceso sea intercambiado fuera si no ha estado cierto tiempo dado en memoria.

En la versión 4.3BSD el espacio de intercambio esta alojado en porciones que son múltiples de potencias de 2 y el tamaño mínimo es (de por ejemplo 32 paginas) mayor al máximo que se determina para el tamaño de intercambio de la partición en disco.

Otra estrategia de manejo de memoria es la paginación. Con esta estrategia la fragmentación externa se elimina pero (como nada es perfkcto) aparece lajkgmentrición uitmro. Si se toman tamaños de pagina lo suñcientemente pequeños pero a la vez adecuados para el manejo dicha fragmentación se reduce considerablemente. Con esto el intercambio puede reducirse al mínimo (desgraciadamente es imposible evitarlo completamente) debido a que mas tareas pueden mantenerse en memoria principal.

UM manera directa de establecer la paginación es usando el algonbno depqhCreián par &manda.

Cuando un proceso necesita UM pagina y esta no se encuentra se activa en el kernel, un status de ”falta de pagina”, entonces se establece un cierto marco para alojar la memoria necesaria y se lee del disco la pagina requerida.

En este caso existen varias mejoras. Si la pagina que se necesita aun permanece en la tabla de paginas

para el proceso, pero se marco como invdida por el proceso de remplazo de paginas, se remarca

como

valida y vuelve a usarse sin necesidad de hacer transferencia de

E/S.

Igualmente pueden ser traídas desde la lista de marcos libres. Cuando varios procesos inician, varias de sus paginas son preparadas y puestas en UM lista libre para recuperarse mediante el mecanismo dado arriba.

Si alp^ pagina debe

localizarse

en disco debe marcarse corno bloqueada en memoria durante la transferencia para asegurar así que la p g i ~ sea elegida como reemplazo.

Existe un algoritmo

mas

interesante llamado rernplaro de p.ginu que se aplica con diversas mejoras y cambios. En la versión 4.3BSD usa el algoritmo

modificado

LRU

(lap1 recently usen). La proyección de toda la memoria principal que no este reservada por el kmel

( U d

core map ó cmap) es recorrida lineaimente repetidamente por

una

rutina especial activada por tiempos (cluck bond o que podría llamarse

dcmonw

de

hmih).

La rutina de clock hand busca por aquellos espacios en memoria que se encuentren completamente libres pero que además satisfagan las necesidades de alojamiento

(marco

de memoria) de quien lo activo. Inmediatamente este espacio se marca como no válido y se saca de la lista de marcos libres. Aquí deben realizarse diversas verificaciones para asegurar el número de paginas validas, para un proceso, no decaiga mas de cierta cota inferor para mantener cubierta la situación de un desbordamiento por parte del dispositivo de paginación. También se asignan ciertos limites de fiontera que no pueden exceder los procesos en su ocupación de memoria.

El algoritmo LRU con clock hand esta implementado totalmente por el demonio de paginación, el cual es el proceso 2 (debe recordarse que el sclwhler es el proceso O e init

es

el 1)’. Este proceso pasa la mayor parte de su existencia “durmiendo”, pero se realiza por el scheduler una revisión si es necesaria la intervención de este demonio, si es así, entonces el proceso 2 es despertado activando con esto el mecanismo de tiempos fuera (descrito en la sección de scheduling de CPU en este texto) para el propio

*

cuando se ananca ei sisienta nix se establecen en memoria una serie & procesos basim imiispensabies pu;i ia