AppleTalk es un conjunto de protocolos de red desarrollado por Apple Computer para sus computadoras Macintosh que ya no se fabrica . AppleTalk incluye una serie de funciones que permiten conectar redes de área local sin necesidad de configuración previa o de un enrutador o servidor centralizado de ningún tipo. Los sistemas conectados equipados con AppleTalk asignan direcciones automáticamente, actualizan el espacio de nombres distribuido y configuran cualquier enrutamiento entre redes requerido.
AppleTalk se lanzó en 1985 y fue el protocolo principal utilizado por los dispositivos Apple durante las décadas de 1980 y 1990. También se lanzaron versiones para IBM PC y compatibles y Apple IIGS . El soporte de AppleTalk también estaba disponible en la mayoría de las impresoras en red (especialmente impresoras láser ), algunos servidores de archivos y varios enrutadores .
El auge de TCP/IP durante la década de 1990 condujo a una reimplementación de la mayoría de estos tipos de soporte en ese protocolo, y AppleTalk dejó de ser compatible a partir del lanzamiento de Mac OS X v10.6 en 2009. Muchas de las funciones de configuración automática más avanzadas de AppleTalk se han introducido desde entonces en Bonjour , mientras que Universal Plug and Play satisface necesidades similares.
Tras el lanzamiento de la computadora Apple Lisa en enero de 1983, Apple invirtió un esfuerzo considerable en el desarrollo de un sistema de red de área local (LAN) para las máquinas. Conocido como AppleNet , se basaba en la pila de protocolos seminal Xerox XNS [1] pero se ejecutaba en un sistema de cable coaxial personalizado de 1 Mbit/s en lugar del Ethernet de 2,94 Mbit/s de Xerox . AppleNet se anunció a principios de 1983 con una introducción completa al precio objetivo de $500 para tarjetas AppleNet enchufables para Lisa y Apple II . [2]
En esa época, los primeros sistemas LAN estaban recién saliendo al mercado, entre ellos Ethernet , Token Ring , Econet y ARCNET . Este era un tema de gran interés comercial en ese momento, dominando eventos como la Conferencia Nacional de Computación (NCC) en Anaheim en mayo de 1983. Todos los sistemas competían por posicionarse en el mercado, pero incluso en ese momento, la aceptación generalizada de Ethernet sugería que se convertiría en un estándar de facto . [3] Fue en este evento que Steve Jobs le hizo a Gursharan Sidhu una pregunta aparentemente inocua: "¿Por qué las redes no se han popularizado?" [4]
Cuatro meses después, en octubre, AppleNet fue cancelado. En ese momento, anunciaron que "Apple se dio cuenta de que no era su negocio crear un sistema de redes. Construimos y usamos AppleNet internamente, pero nos dimos cuenta de que si lo hubiéramos lanzado, habríamos visto surgir nuevos estándares". [5] En enero, Jobs anunció que en su lugar darían soporte a Token Ring de IBM , que esperaba que saliera en "unos pocos meses". [5]
Durante este período, Apple se encontraba inmersa en el desarrollo de la computadora Macintosh. Durante el desarrollo, los ingenieros habían tomado la decisión de utilizar el chip controlador serial Zilog 8530 (SCC) en lugar del UART , más común y de menor costo , para proporcionar conexiones de puerto serial . [6] El SCC costaba aproximadamente $5 más que un UART, pero ofrecía velocidades mucho más altas de hasta 250 kilobits por segundo (o más con hardware adicional) y admitía internamente una serie de protocolos básicos similares a los de redes, como Bisync de IBM . [7]
Se eligió el SCC porque permitiría conectar varios dispositivos al puerto. Los periféricos equipados con SCC similares podrían comunicarse utilizando los protocolos integrados, intercalando sus datos con otros periféricos en el mismo bus. Esto eliminaría la necesidad de más puertos en la parte posterior de la máquina y permitiría la eliminación de ranuras de expansión para admitir dispositivos más complejos. El concepto inicial se conocía como AppleBus y preveía un sistema controlado por el Macintosh anfitrión que sondeaba dispositivos "tontos" de una manera similar al moderno Universal Serial Bus . [8]
El equipo Macintosh ya había comenzado a trabajar en lo que se convertiría en LaserWriter y había considerado otras opciones para responder a la pregunta de cómo compartir estas costosas máquinas y otros recursos. Una serie de memorandos de Bob Belleville aclararon estos conceptos, describiendo el Mac, LaserWriter y un sistema de servidor de archivos que se convertiría en Macintosh Office . [4] A fines de 1983, estaba claro que Token Ring de IBM no estaría listo a tiempo para el lanzamiento del Mac, y podría perderse también el lanzamiento de estos otros productos. Al final, Token Ring no se comercializaría hasta octubre de 1985. [9]
La pregunta anterior de Jobs a Sidhu ya había suscitado una serie de ideas. Cuando AppleNet se canceló en octubre, Sidhu lideró un esfuerzo para desarrollar un nuevo sistema de redes basado en el hardware AppleBus. Este nuevo sistema no tendría que ajustarse a ninguna de las preconcepciones existentes y estaba diseñado para ser digno del Mac: un sistema que fuera instalable por el usuario y no requiriera configuración ni direcciones de red fijas; en resumen, una verdadera red plug-and-play. [10] [ fuente de terceros necesaria ] Se necesitó un esfuerzo considerable, pero cuando se lanzó el Mac, los conceptos básicos ya se habían esbozado y algunos de los protocolos de bajo nivel estaban en camino de completarse. Sidhu mencionó el trabajo a Belleville solo dos horas después de que se anunciara el Mac. [4]
El "nuevo" AppleBus se anunció a principios de 1984, [N 1] permitiendo la conexión directa desde el Mac o Lisa a través de una pequeña caja que se conecta al puerto serie y mediante cables al siguiente ordenador en sentido ascendente y descendente. También se anunciaron adaptadores para Apple II y Apple III . [11] Apple también anunció que una red AppleBus podría conectarse a un sistema Token Ring y que parecería ser un nodo único dentro de él. [5] Los detalles de cómo funcionaría esto eran incompletos. [5]
Justo antes de su lanzamiento a principios de 1985, AppleBus pasó a llamarse AppleTalk . Inicialmente comercializado como AppleTalk Personal Network , comprendía una familia de protocolos de red y una capa física.
La capa física tenía una serie de limitaciones, entre ellas una velocidad de tan solo 230,4 kbit/s, una distancia máxima de 300 m de extremo a extremo y solo 32 nodos por LAN. [12] Pero como el hardware básico estaba integrado en el Mac, añadir nodos solo costaba unos 50 dólares por la caja adaptadora. En comparación, las tarjetas Ethernet o Token Ring cuestan cientos o miles de dólares. Además, toda la pila de red requería solo unos 6 kB de RAM, lo que le permitía funcionar en cualquier Mac. [13]
La velocidad relativamente lenta de AppleTalk permitió reducir aún más los costos. En lugar de utilizar los circuitos de transmisión y recepción balanceados de RS-422 , el cableado de AppleTalk utilizaba una única toma de tierra eléctrica común , lo que limitaba las velocidades a unos 500 kbit/s, pero permitía quitar un conductor. Esto significaba que se podían utilizar cables comunes de tres conductores para el cableado. Además, los adaptadores estaban diseñados para ser "autoterminantes", lo que significa que los nodos al final de la red podían simplemente dejar su último conector sin conectar. No era necesario volver a conectar los cables en un bucle, ni tampoco había necesidad de concentradores u otros dispositivos.
El sistema fue diseñado para una expansión futura; el sistema de direccionamiento permitió la expansión a 255 nodos en una LAN (aunque solo se podían usar 32 en ese momento), y mediante el uso de "puentes" (que llegaron a conocerse como "routers", aunque técnicamente no son lo mismo) se podían interconectar LAN en conjuntos más grandes. Las "zonas" permitían direccionar dispositivos dentro de una Internet conectada mediante puentes. Además, AppleTalk fue diseñado desde el principio para permitir su uso con cualquier enlace físico subyacente potencial, [14] y en pocos años, la capa física pasaría a llamarse LocalTalk , para diferenciarla de los protocolos AppleTalk.
La principal ventaja de AppleTalk era que no requería ningún tipo de mantenimiento. Para conectar un dispositivo a una red, el usuario simplemente conectaba el adaptador a la máquina y luego conectaba un cable desde ella a cualquier puerto libre de cualquier otro adaptador. La pila de red AppleTalk negociaba una dirección de red, asignaba al ordenador un nombre legible por humanos y compilaba una lista de los nombres y tipos de otros equipos de la red para que el usuario pudiera explorar los dispositivos a través del Selector . AppleTalk era tan fácil de usar que las redes ad hoc tendían a aparecer siempre que había varios Mac en la misma habitación. [15] Más tarde, Apple utilizaría esto en un anuncio que mostraba una red que se estaba creando entre dos asientos de un avión. [16]
En los años siguientes se desarrolló un mercado de terceros muy activo para los dispositivos AppleTalk. Un ejemplo particularmente notable fue un adaptador alternativo diseñado por BMUG y comercializado por Farallon como PhoneNET en 1987. [17] Se trataba básicamente de un reemplazo del conector de Apple que tenía conectores telefónicos convencionales en lugar de los conectores redondos de Apple. PhoneNet permitía conectar redes AppleTalk entre sí mediante cables telefónicos normales y, con muy poco trabajo adicional, podía hacer funcionar teléfonos analógicos y AppleTalk en un solo cable telefónico de cuatro conductores.
Otras compañías aprovecharon la capacidad del SCC de leer relojes externos para soportar velocidades de transmisión más altas, hasta 1 Mbit/s. En estos sistemas, el adaptador externo también incluía su propio reloj y lo usaba para enviar señales a los pines de entrada de reloj del SCC. El sistema más conocido de este tipo era FlashTalk de Centram , que funcionaba a 768 kbit/s y estaba destinado a usarse con su sistema de red TOPS . [18] Una solución similar fue el DaynaTalk de 850 kbit/s , que usaba una caja separada que se conectaba entre la computadora y una caja LocalTalk/PhoneNet normal. Dayna también ofrecía una tarjeta de expansión para PC que funcionaba hasta 1,7 Mbit/s cuando se comunicaba con otras tarjetas Dayna para PC. [19] [20] También existían otros sistemas con un rendimiento aún mayor, pero estos a menudo requerían un cableado especial que era incompatible con LocalTalk/PhoneNet y también requerían parches a la pila de red que a menudo causaban problemas.
A medida que Apple se expandía hacia mercados más comerciales y educativos, necesitaba integrar AppleTalk en las instalaciones de red existentes. Muchas de estas organizaciones ya habían invertido en una infraestructura Ethernet muy costosa y no había una forma directa de conectar un Macintosh a Ethernet. AppleTalk incluía una estructura de protocolo para interconectar subredes AppleTalk y, como solución, se creó inicialmente EtherTalk para utilizar Ethernet como red troncal entre subredes LocalTalk. Para lograr esto, las organizaciones necesitarían comprar un puente LocalTalk-a-Ethernet y Apple dejó que terceros produjeran estos productos. [21] Varias empresas respondieron, incluidas Hayes y algunas empresas de nueva creación como Kinetics.
En 1987, Ethernet estaba claramente ganando la batalla de los estándares sobre Token Ring y, a mediados de ese año, Apple presentó EtherTalk 1.0 , una implementación del protocolo AppleTalk sobre la capa física de Ethernet. Presentado para la computadora Macintosh II recién lanzada , una de las dos primeras Macintosh de Apple con ranuras de expansión (la Macintosh SE tenía una ranura de un tipo diferente), el sistema operativo incluía un nuevo panel de control de red que permitía al usuario seleccionar qué conexión física usar para la red (desde "Built-in" o "EtherTalk"). En el momento de la presentación, las tarjetas de interfaz Ethernet estaban disponibles en 3Com y Kinetics que se conectaban a una ranura Nubus en la máquina. La nueva pila de redes también amplió el sistema para permitir un total de 255 nodos por LAN. Con el lanzamiento de EtherTalk, AppleTalk Personal Network pasó a llamarse LocalTalk , [22] el nombre con el que sería conocido durante la mayor parte de su vida. Más tarde, Token Ring sería compatible con un producto TokenTalk similar , que utilizaba el mismo panel de control de red y el mismo software subyacente. Con el tiempo, muchas empresas de terceros lanzarían tarjetas Ethernet y Token Ring compatibles que utilizaban estos mismos controladores.
La aparición de un Macintosh con una conexión Ethernet directa también magnificó el problema de compatibilidad de Ethernet y LocalTalk: las redes con Macs nuevos y viejos necesitaban alguna forma de comunicarse entre sí. Esto podía ser tan simple como una red de Mac II con Ethernet que intentaba comunicarse con un LaserWriter que sólo se conectaba a LocalTalk. Apple inicialmente dependía de los productos puente de LocalTalk a Ethernet antes mencionados, pero contrariamente a la creencia de Apple de que estos serían productos de bajo volumen, a fines de 1987, 130.000 de esas redes estaban en uso. AppleTalk era en ese momento el sistema de red más utilizado en el mundo, con más del triple de instalaciones que cualquier otro proveedor. [23] [ fuente de terceros necesaria ]
1987 también marcó la introducción del producto AppleShare , un servidor de archivos dedicado que funcionaba en cualquier Mac con 512 kB de RAM o más. Una máquina AppleShare común era la Mac Plus con un disco duro SCSI externo . AppleShare fue el tercer sistema operativo de red a fines de la década de 1980, detrás de Novell NetWare y MS-Net de Microsoft . [24] AppleShare fue efectivamente el reemplazo de los fallidos esfuerzos de Macintosh Office, que se habían basado en un dispositivo de servidor de archivos dedicado.
En 1989 se lanzó un rediseño significativo con el nombre de AppleTalk Phase II . En muchos sentidos, la Phase II puede considerarse un esfuerzo por hacer que la versión anterior (nunca llamada Phase I) fuera más genérica. Las LAN podían ahora admitir más de 255 nodos y las zonas ya no estaban asociadas con redes físicas sino que eran construcciones completamente virtuales utilizadas simplemente para organizar nodos. Por ejemplo, ahora se podía crear una zona de "Impresoras" que enumerara todas las impresoras de una organización, o se podía querer colocar ese mismo dispositivo en la zona del "2.º piso" para indicar su ubicación física. La Phase II también incluyó cambios en los protocolos de interconexión de redes subyacentes para hacerlos menos "parlantes", lo que anteriormente había sido un problema grave en las redes que se conectaban a través de redes de área amplia. [25]
En ese momento, Apple tenía una amplia variedad de productos de comunicaciones en desarrollo, y muchos de ellos se anunciaron junto con AppleTalk Phase II. Entre ellos se encontraban actualizaciones de EtherTalk y TokenTalk, software AppleTalk y hardware LocalTalk para IBM PC , EtherTalk para el sistema operativo A/UX de Apple, que le permitía utilizar LaserWriters y otros recursos de red, y los productos Mac X.25 y MacX .
En 1990, Ethernet se había vuelto casi universal y era hora de integrar Ethernet en los Mac directamente desde la fábrica. Sin embargo, el cableado físico utilizado por estas redes aún no estaba completamente estandarizado. Apple resolvió este problema utilizando un solo puerto en la parte posterior del ordenador en el que el usuario podía conectar un adaptador para cualquier sistema de cableado. Este sistema FriendlyNet se basaba en la interfaz de unidad de conexión o AUI (por sus siglas en inglés) estándar de la industria, pero eligió deliberadamente un conector no estándar que era más pequeño y más fácil de usar, al que llamaron "Apple AUI" o AAUI . FriendlyNet se introdujo por primera vez en los ordenadores Quadra 700 y Quadra 900 , y se utilizó en gran parte de la línea Mac durante algún tiempo. [26] Al igual que con LocalTalk, rápidamente aparecieron varios adaptadores FriendlyNet de terceros.
A medida que 10BASE-T se convirtió en el sistema de cableado de facto para Ethernet, las máquinas Power Macintosh de segunda generación agregaron un puerto 10BASE-T además de AAUI. El PowerBook 3400c y los Power Mac de gama baja también agregaron 10BASE-T. Los Power Macintosh 7300 / 8600 / 9600 fueron los últimos Mac en incluir AAUI, y 10BASE-T se volvió universal a partir de los Power Macintosh G3 y PowerBook G3 .
Desde el comienzo de AppleTalk, los usuarios querían conectar el Macintosh a entornos de red TCP/IP . En 1984, Bill Croft de la Universidad de Stanford fue pionero en el desarrollo de paquetes IP encapsulados en DDP como parte del proyecto SEAGATE (Stanford Ethernet–AppleTalk Gateway). SEAGATE fue comercializado por Kinetics en su puente LocalTalk-to-Ethernet como una opción de enrutamiento adicional. Unos años más tarde, MacIP se separó del código SEAGATE y se convirtió en el método de facto para enrutar paquetes IP a través de redes LocalTalk. En 1986, la Universidad de Columbia lanzó la primera versión del Paquete AppleTalk de Columbia (CAP) que permitía una mayor integración de entornos Unix, TCP/IP y AppleTalk. En 1988, Apple lanzó MacTCP , un sistema que permitía al Mac soportar TCP/IP en máquinas con hardware Ethernet adecuado. Sin embargo, esto dejó a muchas universidades con el problema de soportar IP en sus muchos Mac equipados con LocalTalk. Pronto se hizo común incluir soporte para MacIP en los puentes LocalTalk a Ethernet. [26] MacTCP no se convertiría en una parte estándar del Mac OS clásico hasta 1994, [27] momento en el que también soportaba SNMP y PPP .
Durante algún tiempo a principios de la década de 1990, Mac fue un cliente principal en la Internet en rápida expansión. [ cita requerida ] Entre los programas más conocidos y de uso generalizado estaban Fetch, Eudora, eXodus, NewsWatcher y los paquetes NCSA, especialmente NCSA Mosaic [28] y su descendencia, Netscape Navigator . [29] Además, aparecieron varios productos de servidor que permitieron a Mac alojar contenido de Internet. Durante este período, los Mac tenían aproximadamente entre 2 y 3 veces más clientes conectados a Internet que cualquier otra plataforma, [30] [ fuente de terceros necesaria ] a pesar de la participación relativamente pequeña en el mercado general de microcomputadoras.
A medida que el mundo se trasladaba rápidamente a IP tanto para usos de LAN como de WAN, Apple se enfrentó a la necesidad de mantener dos bases de código cada vez más obsoletas en un grupo cada vez más amplio de máquinas, así como a la introducción de las máquinas basadas en PowerPC . Esto condujo a los esfuerzos de Open Transport , que reimplementaron tanto MacTCP como AppleTalk en una base de código completamente nueva adaptada del estándar Unix STREAMS . Las primeras versiones tuvieron problemas y no se volvieron estables durante algún tiempo. [31] En ese momento, Apple estaba inmerso en sus esfuerzos de Copland, que finalmente fracasaron .
Con la compra de NeXT y el posterior desarrollo de Mac OS X , AppleTalk pasó a ser estrictamente un sistema heredado. Se agregó soporte a Mac OS X para brindar soporte a una gran cantidad de dispositivos AppleTalk existentes, en particular impresoras láser y recursos compartidos de archivos, pero las soluciones de conexión alternativas comunes en esta era, en particular USB para impresoras, limitaron su demanda. A medida que Apple abandonó muchas de estas categorías de productos y todos los sistemas nuevos se basaron en IP, AppleTalk se volvió cada vez menos común. El soporte de AppleTalk finalmente se eliminó de la línea macOS en Mac OS X v10.6 en 2009. [32]
Sin embargo, la pérdida de AppleTalk no redujo el deseo de soluciones de red que combinaran su facilidad de uso con el enrutamiento IP. Apple ha liderado el desarrollo de muchos de estos esfuerzos, desde la introducción del enrutador AirPort hasta el desarrollo del sistema de red de configuración cero y su implementación, Rendezvous, posteriormente rebautizado como Bonjour .
A partir de 2020, la compatibilidad con AppleTalk se ha eliminado por completo del soporte heredado con macOS 11 Big Sur.
El diseño de AppleTalk siguió rigurosamente el modelo OSI de capas de protocolos. A diferencia de la mayoría de los primeros sistemas LAN , AppleTalk no se construyó utilizando el sistema XNS arquetípico de Xerox . El objetivo previsto no era Ethernet y no tenía direcciones de 48 bits para enrutar. Sin embargo, muchas partes del sistema AppleTalk tienen análogos directos en XNS.
Una diferencia clave para AppleTalk era que contenía dos protocolos destinados a hacer que el sistema se autoconfigurara por completo. El protocolo de resolución de direcciones AppleTalk ( AARP ) permitía a los hosts AppleTalk generar automáticamente sus propias direcciones de red, y el protocolo de enlace de nombres ( NBP ) era un sistema dinámico para asignar direcciones de red a nombres legibles por el usuario. Aunque existían sistemas similares a AARP en otros sistemas, Banyan VINES por ejemplo. A partir de 2002, Rendezvous (la combinación de descubrimiento de servicios basado en DNS , DNS de multidifusión y direccionamiento local de enlace ) proporcionó capacidades y usabilidad utilizando IP que eran similares a las de AppleTalk. [33] [34]
Tanto AARP como NBP habían definido formas de permitir que los dispositivos "controladores" anularan los mecanismos predeterminados. El concepto era permitir que los enrutadores proporcionaran la información o "conectaran" el sistema a direcciones y nombres conocidos. En redes más grandes donde AARP podía causar problemas a medida que los nuevos nodos buscaban direcciones libres, la adición de un enrutador podía reducir la "conversación". Juntos, AARP y NBP hicieron de AppleTalk un sistema de redes fácil de usar. Se añadían nuevas máquinas a la red conectándolas y dándoles un nombre opcional. Las listas de NBP se examinaban y mostraban mediante un programa conocido como Chooser , que mostraba una lista de máquinas en la red local, dividida en clases como servidores de archivos e impresoras.
Una dirección AppleTalk era una cantidad de cuatro bytes. Esta consistía en un número de red de dos bytes, un número de nodo de un byte y un número de socket de un byte. De estos, solo el número de red requería alguna configuración, al obtenerse de un enrutador. Cada nodo elegía dinámicamente su propio número de nodo, de acuerdo con un protocolo (originalmente el Protocolo de acceso a enlaces LocalTalk LLAP y más tarde, para Ethernet/EtherTalk, el Protocolo de resolución de direcciones AppleTalk, AARP) [35] que manejaba la contención entre diferentes nodos que elegían accidentalmente el mismo número. Para los números de socket, algunos números bien conocidos se reservaban para propósitos especiales específicos del propio protocolo AppleTalk. Aparte de estos, se esperaba que todos los protocolos de nivel de aplicación usaran números de socket asignados dinámicamente tanto en el extremo del cliente como del servidor.
Debido a este dinamismo, no se podía esperar que los usuarios accedieran a los servicios especificando su dirección. En cambio, todos los servicios tenían nombres que, al ser elegidos por humanos, se podía esperar que fueran significativos para los usuarios y, además, podían ser lo suficientemente largos para minimizar la posibilidad de conflictos.
Como los nombres NBP se traducían a una dirección, que incluía un número de socket y un número de nodo, un nombre en AppleTalk se asignaba directamente a un servicio proporcionado por una máquina, que era totalmente independiente del nombre de la máquina en sí. Por lo tanto, los servicios se podían mover a una máquina diferente y, siempre que mantuvieran el mismo nombre de servicio, no era necesario que los usuarios hicieran nada diferente para seguir accediendo al servicio. Y la misma máquina podía albergar cualquier cantidad de instancias de servicios del mismo tipo, sin ningún conflicto de conexión de red.
Comparemos esto con los registros A en el DNS , en los que un nombre se traduce a la dirección de una máquina, sin incluir el número de puerto que podría estar proporcionando un servicio. Por lo tanto, si las personas están acostumbradas a usar un nombre de máquina particular para acceder a un servicio en particular, su acceso se interrumpirá cuando el servicio se traslade a una máquina diferente. Esto se puede mitigar en cierta medida insistiendo en usar registros CNAME que indiquen el servicio en lugar de los nombres reales de las máquinas para referirse al servicio, pero no hay forma de garantizar que los usuarios sigan esa convención. Algunos protocolos más nuevos, como Kerberos y Active Directory, usan registros SRV de DNS para identificar servicios por nombre, lo que se acerca mucho más al modelo AppleTalk. [ ¿ Investigación original? ]
El protocolo de resolución de direcciones AppleTalk (AARP) resuelve direcciones AppleTalk en direcciones de capa de enlace . [36] Es funcionalmente equivalente a ARP y obtiene la resolución de direcciones mediante un método muy similar a ARP.
AARP es un sistema bastante simple. Cuando se enciende, una máquina AppleTalk transmite un paquete de sondeo AARP solicitando una dirección de red, con la intención de recibir respuesta de controladores como enrutadores. Si no se proporciona una dirección, se elige una al azar de la "subred base", 0. Luego transmite otro paquete que dice "Estoy seleccionando esta dirección", y luego espera para ver si alguien más en la red se queja. Si otra máquina tiene esa dirección, la máquina que se acaba de conectar elegirá otra dirección y seguirá intentándolo hasta que encuentre una libre. [37] En una red con muchas máquinas, pueden necesitarse varios intentos antes de encontrar una dirección libre, por lo que, por motivos de rendimiento, la dirección exitosa se registra en NVRAM y se usa como la dirección predeterminada en el futuro. Esto significa que en la mayoría de las configuraciones del mundo real donde se agregan máquinas unas pocas a la vez, solo se necesitan uno o dos intentos antes de que la dirección se vuelva efectivamente constante.
El protocolo de transmisión de datos AppleTalk (ADSP) fue una incorporación relativamente tardía al conjunto de protocolos AppleTalk, que se realizó cuando se hizo evidente que se necesitaba un transporte orientado a la conexión confiable al estilo TCP . Las diferencias significativas con respecto a TCP eran las siguientes:
El protocolo Apple Filing Protocol (AFP), anteriormente AppleTalk Filing Protocol, es el protocolo para comunicarse con los servidores de archivos AppleShare . Desarrollado sobre el protocolo de sesión AppleTalk (para el AFP heredado sobre DDP) o la interfaz de flujo de datos (para AFP sobre TCP), proporciona servicios para autenticar usuarios (extensible a diferentes métodos de autenticación, incluido el intercambio de números aleatorios bidireccional) y para realizar operaciones específicas del sistema de archivos HFS de Macintosh . AFP todavía se utiliza en macOS, aunque la mayoría de los demás protocolos AppleTalk han quedado obsoletos.
El protocolo de sesión AppleTalk (ASP) era un protocolo intermedio, construido sobre el protocolo de transacción AppleTalk (ATP), que a su vez era la base de AFP. Proporcionaba servicios básicos para solicitar respuestas a comandos arbitrarios y realizar consultas de estado fuera de banda. También permitía que el servidor enviara mensajes de atención asincrónicos al cliente.
El protocolo de transacciones AppleTalk (ATP) fue el protocolo original fiable de nivel de transporte para AppleTalk, construido sobre DDP. En el momento de su desarrollo, se consideró que un protocolo orientado a la conexión completo y fiable como TCP era demasiado caro de implementar para la mayoría de los usos previstos de AppleTalk. Por lo tanto, ATP era un simple intercambio de solicitud/respuesta, sin necesidad de establecer o desmantelar conexiones.
Un paquete de solicitud ATP puede ser respondido con hasta ocho paquetes de respuesta . El solicitante envía entonces un paquete de confirmación que contiene una máscara de bits que indica cuál de los paquetes de respuesta recibió, de modo que el respondedor pueda retransmitir el resto.
El ATP podía funcionar en modo "al menos una vez" o en modo "exactamente una vez". El modo exactamente una vez era esencial para operaciones que no eran idempotentes ; en este modo, el respondedor guardaba una copia de los buffers de respuesta en la memoria hasta que recibía con éxito un paquete de liberación del solicitante, o hasta que transcurría un tiempo de espera. De esta manera, podía responder a solicitudes duplicadas con el mismo ID de transacción reenviando los mismos datos de respuesta, sin realizar la operación real nuevamente. [39]
El Protocolo de Entrega de Datagramas (DDP) era el protocolo de transporte independiente del enlace de datos de nivel más bajo. Proporcionaba un servicio de datagramas sin garantías de entrega. Todos los protocolos de nivel de aplicación, incluidos los protocolos de infraestructura NBP, RTMP y ZIP, se construyeron sobre el DDP. El DDP de AppleTalk se corresponde estrechamente con la capa de red del modelo de comunicación de interconexión de sistemas abiertos ( OSI ).
El Protocolo de Vinculación de Nombres (NBP) era un sistema distribuido y dinámico para gestionar los nombres de AppleTalk. Cuando un servicio se iniciaba en una máquina, registraba un nombre para sí mismo elegido por un administrador humano. En ese momento, NBP proporcionaba un sistema para comprobar que ninguna otra máquina había registrado ya el mismo nombre. Más tarde, cuando un cliente quería acceder a ese servicio, utilizaba NBP para consultar a las máquinas para encontrar ese servicio. NBP proporcionaba navegabilidad ("¿cuáles son los nombres de todos los servicios disponibles?") así como la capacidad de encontrar un servicio con un nombre en particular. [36] Los nombres eran legibles para humanos, contenían espacios y letras mayúsculas y minúsculas, e incluían soporte para búsquedas.
El protocolo AppleTalk Echo Protocol (AEP) fue un protocolo de capa de transporte diseñado para probar la accesibilidad de los nodos de red. [36] AEP genera paquetes para ser enviados al nodo de red y se identifica en el campo Tipo de un paquete como un paquete AEP. El paquete primero se pasa al DDP de origen. Después de que se identifica como un paquete AEP, se reenvía al nodo donde el paquete es examinado por el DDP en el destino. Después de que el paquete se identifica como un paquete AEP, el paquete se copia y se altera un campo en el paquete para crear un paquete de respuesta AEP, y luego se devuelve al nodo de origen.
El protocolo de acceso a impresoras (PAP) era la forma estándar de comunicarse con las impresoras PostScript . Se construyó sobre ATP. [36] Cuando se abría una conexión PAP, cada extremo enviaba al otro una solicitud ATP que básicamente significaba "envíame más datos". La respuesta del cliente al servidor era enviar un bloque de código PostScript, mientras que el servidor podía responder con cualquier mensaje de diagnóstico que pudiera generarse como resultado, después de lo cual se enviaba otra solicitud de "envía más datos". Este uso de ATP proporcionaba un control de flujo automático ; cada extremo solo podía enviar datos al otro extremo si había una solicitud ATP pendiente a la que responder.
PAP también permitía realizar consultas de estado fuera de banda, gestionadas por transacciones ATP independientes. Incluso mientras estaba ocupado atendiendo un trabajo de impresión de un cliente, un servidor PAP podía seguir respondiendo a solicitudes de estado de cualquier número de otros clientes. Esto permitía que otros Macintosh de la LAN que estaban esperando para imprimir mostraran mensajes de estado que indicaban que la impresora estaba ocupada y en qué trabajo estaba trabajando.
El Protocolo de Mantenimiento de Tabla de Enrutamiento (RTMP) era el protocolo mediante el cual los enrutadores se mantenían informados entre sí sobre la topología de la red. [36] Esta era la única parte de AppleTalk que requería transmisiones periódicas no solicitadas: cada 10 segundos, cada enrutador tenía que enviar una lista de todos los números de red que conocía y qué tan lejos pensaba que estaban.
El Protocolo de Información de Zona (ZIP) era el protocolo mediante el cual los números de red de AppleTalk se asociaban con los nombres de zona. [36] Una zona era una subdivisión de la red que tenía sentido para los humanos (por ejemplo, "Departamento de Contabilidad"); pero mientras que un número de red tenía que asignarse a una sección topológicamente contigua de la red, una zona podía incluir varias porciones discontinuas diferentes de la red.
La implementación inicial predeterminada de hardware para AppleTalk era un protocolo serial de alta velocidad conocido como LocalTalk que utilizaba los puertos RS-422 integrados de Macintosh a 230,4 kbit/s. LocalTalk utilizaba un divisor en el puerto RS-422 para proporcionar un cable de subida y bajada desde un único puerto. La topología era un bus : los cables se conectaban en cadena desde cada máquina conectada a la siguiente, hasta el máximo de 32 permitido en cualquier segmento LocalTalk . El sistema era lento para los estándares actuales, pero en ese momento el costo adicional y la complejidad de la conexión en red en las máquinas PC era tal que era común que las Mac fueran las únicas computadoras personales en red en una oficina. Otras computadoras más grandes, como las estaciones de trabajo UNIX o VAX, comúnmente se conectaban en red a través de Ethernet.
También había otras implementaciones físicas disponibles. Un reemplazo muy popular para LocalTalk era PhoneNET , una solución de terceros de Farallon Computing, Inc. (renombrada Netopia , adquirida por Motorola en 2007) que también usaba el puerto RS-422 y era indistinguible de LocalTalk en lo que respecta a los controladores de puerto LocalTalk de Apple, pero funcionaba sobre un cableado telefónico estándar muy económico con conectores modulares de cuatro cables y seis posiciones , los mismos cables que se usan para conectar teléfonos fijos. Dado que usaba el segundo par de cables, los dispositivos de red incluso se podían conectar a través de conectores telefónicos existentes si no había una segunda línea. Anticipando los concentradores y conmutadores de red actuales, Farallon proporcionó soluciones para que PhoneNet se usara en configuraciones en estrella y en bus , con conexiones en estrella pasivas (con los cables telefónicos simplemente conectados entre sí en un punto central) y en estrella activa con hardware de concentrador "PhoneNet Star Controller". En una configuración en estrella, cualquier problema de cableado solo afectaba a un dispositivo y los problemas eran fáciles de detectar. El bajo costo, la flexibilidad y la fácil resolución de problemas de PhoneNet hicieron que fuera la opción dominante para las redes Mac hasta principios de la década de 1990.
Los protocolos AppleTalk también llegaron a funcionar sobre las capas físicas de Ethernet (primero coaxial y luego de par trenzado) y Token Ring , denominadas por Apple como EtherTalk y TokenTalk , respectivamente. EtherTalk se convirtió gradualmente en el método de implementación dominante para AppleTalk a medida que Ethernet se hizo popular en la industria de las PC durante la década de 1990. Además de AppleTalk y TCP/IP , cualquier red Ethernet también podía transportar simultáneamente otros protocolos como DECnet e IPX .
Cuando se presentó AppleTalk por primera vez, la plataforma informática de oficina dominante era la compatible con PC que ejecutaba MS-DOS. Apple presentó la tarjeta AppleTalk PC a principios de 1987, que permitía a los PC unirse a redes AppleTalk e imprimir en impresoras LaserWriter. [40] Un año después se lanzó AppleShare PC, que permitía a los PC acceder a los servidores de archivos AppleShare. [41]
El sistema de red MS-DOS "TOPS Teleconnector" [42] sobre el sistema AppleTalk permitía a los PC MS-DOS comunicarse a través del hardware de red AppleTalk; comprendía una tarjeta de interfaz AppleTalk para el PC y un conjunto de software de red que permitía funciones como compartir archivos, unidades e impresoras. Además de permitir la construcción de una red AppleTalk sólo para PC, permitía la comunicación entre PC y Mac con el software TOPS instalado. (Los Mac sin TOPS instalado podían utilizar la misma red pero sólo para comunicarse con otras máquinas Apple). El software TOPS de Mac no igualaba la calidad del propio Apple ni en facilidad de uso ni en robustez y ausencia de fallos, pero el software DOS era relativamente sencillo de utilizar en términos DOS y era robusto.
Los sistemas operativos BSD y Linux soportan AppleTalk a través de un proyecto de código abierto llamado Netatalk , que implementa el conjunto completo de protocolos y les permite actuar como servidores de archivos o de impresión nativos para computadoras Macintosh, e imprimir en impresoras LocalTalk a través de la red.
Los sistemas operativos Windows Server admitieron AppleTalk a partir de Windows NT y hasta después de Windows Server 2003. Miramar incluyó AppleTalk en su producto PC MacLAN, que CA dejó de fabricar en 2007. GroupLogic sigue incluyendo su protocolo AppleTalk en su software de servidor ExtremeZ-IP para la integración Macintosh-Windows, que admite Windows Server 2008 y Windows Vista , así como versiones anteriores. HELIOS Software GmbH ofrece una implementación patentada de la pila de protocolos AppleTalk, como parte de su servidor HELIOS UB2. Se trata, en esencia, de una suite de servidores de archivos e impresión que se ejecuta en una amplia gama de plataformas diferentes.
Además, la Universidad de Columbia publicó el paquete Columbia AppleTalk (CAP), que implementaba el conjunto de protocolos para varios sistemas Unix, entre ellos Ultrix , SunOS , BSD e IRIX . Este paquete ya no recibe mantenimiento activo.