AppleTalk es un conjunto patentado de protocolos de red desarrollado por Apple Computer para sus computadoras Macintosh . AppleTalk incluye una serie de funciones que permiten conectar redes de área local sin configuración previa ni la necesidad 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 . La compatibilidad con AppleTalk también estaba disponible en la mayoría de las impresoras en red (especialmente las impresoras láser ), algunos servidores de archivos y varios enrutadores .
El auge de TCP/IP durante la década de 1990 llevó 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 ya no son compatibles. desde entonces se introdujo en Bonjour , mientras que Universal Plug and Play satisface necesidades similares.
Después del 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 basó en la pila de protocolos XNS de Xerox [1] pero se ejecutó 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 dólares para tarjetas AppleNet enchufables para Lisa y Apple II . [2]
En ese momento, los primeros sistemas LAN recién llegaban al mercado, incluidos Ethernet , Token Ring , Econet y ARCNET . Este fue un tema de gran esfuerzo comercial en ese momento, dominando espectáculos como la Conferencia Nacional de Computación (NCC) en Anaheim en mayo de 1983. Todos los sistemas competían por una posición en el mercado, pero incluso en ese momento, la aceptación generalizada de Ethernet sugería se convertiría en una norma de facto . [3] Fue en este programa 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, se canceló AppleNet. En ese momento, anunciaron que "Apple se dio cuenta de que no estaba en el negocio crear un sistema de red. Construimos y utilizamos AppleNet internamente, pero nos dimos cuenta de que si lo hubiéramos enviado, habríamos visto surgir nuevos estándares". " [5] En enero, Jobs anunció que, en cambio, respaldarían el Token Ring de IBM , que esperaba que saliera en "unos pocos meses". [5]
Durante este período, Apple estuvo profundamente inmersa en el desarrollo de la computadora Macintosh. Durante el desarrollo, los ingenieros tomaron la decisión de utilizar el chip controlador serie (SCC) Zilog 8530 en lugar del UART más común y de menor costo para proporcionar conexiones de puerto serie . [6] El SCC costaba alrededor de $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 soportaba internamente una serie de protocolos básicos similares a redes, como Bisync de IBM . [7]
Se eligió el SCC porque permitiría conectar múltiples dispositivos al puerto. Los periféricos equipados con SCC similares podrían comunicarse utilizando los protocolos integrados, entrelazando 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 , imaginando un sistema controlado por el host Macintosh que sondeaba dispositivos "tontos" de una manera similar al moderno Universal Serial Bus . [8]
El equipo de 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 Mac, LaserWriter y un sistema de servidor de archivos que se convertiría en Macintosh Office . [4] A finales de 1983 estaba claro que el Token Ring de IBM no estaría listo a tiempo para el lanzamiento de Mac, y podría perderse también el lanzamiento de estos otros productos. Al final, Token Ring no se enviaría hasta octubre de 1985. [9]
La pregunta anterior de Jobs a Sidhu ya había generado una serie de ideas. Cuando se canceló AppleNet en octubre, Sidhu lideró un esfuerzo para desarrollar un nuevo sistema de red basado en el hardware AppleBus. Este nuevo sistema no tendría que ajustarse a ninguna idea preconcebida existente y fue diseñado para ser digno de la Mac: un sistema que era instalable por el usuario y no requería configuración ni direcciones de red fijas; en resumen, una verdadera red plug-and-play. . [10] [ se necesita fuente de terceros ] Se necesitó un esfuerzo considerable, pero cuando se lanzó Mac, se habían delineado los conceptos básicos y algunos de los protocolos de bajo nivel estaban en camino de completarse. Sidhu mencionó el trabajo a Belleville sólo dos horas después de que se anunciara la Mac. [4]
El "nuevo" AppleBus se anunció a principios de 1984, [N 1] que permitía la conexión directa desde Mac o Lisa a través de una pequeña caja que se conecta al puerto serie y se conecta mediante cables a la siguiente computadora ascendente y descendente. También se anunciaron adaptadores para Apple II y Apple III . [11] Apple también anunció que se podría conectar una red AppleBus a un sistema Token Ring y que parecería ser un único nodo 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 . Comercializado inicialmente 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, incluida una velocidad de sólo 230,4 kbit/s, una distancia máxima de 300 m (1000 pies) de un extremo a otro y sólo 32 nodos por LAN. [12] Pero como el hardware básico estaba integrado en la Mac, agregar nodos solo costaba alrededor de $50 por la caja del adaptador. 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 sólo unos 6 kB de RAM, lo que le permitía ejecutarse en cualquier Mac. [13]
La velocidad relativamente lenta de AppleTalk permitió mayores reducciones de costos. En lugar de utilizar los circuitos equilibrados de transmisión y recepción del RS-422 , el cableado AppleTalk utilizaba una única conexión a tierra eléctrica común , que limitaba las velocidades a unos 500 kbit/s, pero permitía retirar un conductor. Esto significaba que para el cableado se podían utilizar cables habituales de tres conductores. Además, los adaptadores fueron diseñados para ser "autoterminados", lo que significa que los nodos al final de la red podrían simplemente dejar su último conector desconectado. No era necesario volver a conectar los cables formando un bucle, ni tampoco necesidad de concentradores u otros dispositivos.
El sistema fue diseñado para una futura expansión; el sistema de direccionamiento permitía la expansión a 255 nodos en una LAN (aunque en ese momento sólo se podían usar 32), y mediante el uso de "puentes" (que llegaron a conocerse como "enrutadores", aunque técnicamente no eran lo mismo) se podía interconectar LAN en colecciones más grandes. Las "zonas" permitían direccionar dispositivos dentro de un puente de Internet conectado. Además, AppleTalk fue diseñado desde el principio para permitir su uso con cualquier enlace físico subyacente potencial, [14] y dentro de unos 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 necesitaba ningún mantenimiento. Para unir un dispositivo a una red, un usuario simplemente conectaba el adaptador a la máquina y luego conectaba un cable a cualquier puerto libre de cualquier otro adaptador. La pila de red AppleTalk negoció una dirección de red, asignó a la computadora un nombre legible por humanos y compiló una lista de los nombres y tipos de otras máquinas en 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] Apple usaría esto más tarde en un anuncio que muestra la creación de una red entre dos asientos de un avión. [dieciséis]
En los próximos años se desarrolló un próspero mercado de terceros para dispositivos AppleTalk. Un ejemplo particularmente notable fue un adaptador alternativo diseñado por BMUG y comercializado por Farallon como PhoneNET en 1987. [17] Esto era esencialmente un reemplazo del conector de Apple que tenía conectores telefónicos convencionales en lugar de los conectores redondos de Apple. PhoneNet permitió que las redes AppleTalk se conectaran entre sí mediante cables telefónicos normales y, con muy poco trabajo adicional, podía ejecutar teléfonos analógicos y AppleTalk en un solo cable telefónico de cuatro conductores.
Otras empresas aprovecharon la capacidad del SCC para leer relojes externos para admitir 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 señalar los pines de entrada del reloj del SCC. El sistema más conocido fue FlashTalk de Centram , que funcionaba a 768 kbit/s y estaba destinado a ser utilizado 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 ofreció una tarjeta de expansión para PC que alcanzaba los 1,7 Mbit/s cuando se comunicaba con otras tarjetas para PC Dayna. [19] [20] También existían varios otros sistemas con un rendimiento aún mayor, pero a menudo requerían cableado especial que era incompatible con LocalTalk/PhoneNet, y también requerían parches en la pila de red que a menudo causaban problemas.
A medida que Apple se expandió a mercados más comerciales y educativos, necesitaban 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 una Macintosh a Ethernet. AppleTalk incluía una estructura de protocolo para interconectar subredes AppleTalk y, como solución, EtherTalk se creó inicialmente para utilizar Ethernet como columna vertebral entre las subredes LocalTalk. Para lograr esto, las organizaciones necesitarían comprar un puente LocalTalk-to-Ethernet y Apple dejó a terceros la producción de estos productos. [21] Varias empresas respondieron, incluida Hayes y algunas empresas recién formadas 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. Introducido 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 uso para redes (de "Integrado" o "EtherTalk"). En el momento de su introducción, 3Com y Kinetics ofrecían tarjetas de interfaz Ethernet que se conectaban a una ranura Nubus de la máquina. La nueva pila de redes también amplió el sistema para permitir 255 nodos completos por LAN. Con el lanzamiento de EtherTalk, AppleTalk Personal Network pasó a llamarse LocalTalk , [22] el nombre con el que sería conocida durante la mayor parte de su vida. Posteriormente, 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 introdujeron tarjetas Ethernet y Token Ring compatibles que utilizaban estos mismos controladores.
La aparición de una Macintosh con una conexión Ethernet directa también magnificó el problema de compatibilidad de Ethernet y LocalTalk: las redes con Mac nuevas y antiguas necesitaban alguna forma de comunicarse entre sí. Esto podría ser tan simple como una red Ethernet de Mac II intentando comunicarse con un LaserWriter que solo está conectado a LocalTalk. Apple inicialmente confió en los productos puente LocalTalk-to-Ethernet antes mencionados, pero contrariamente a la creencia de Apple de que serían productos de bajo volumen, a finales de 1987, 130.000 redes de este tipo 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] [ se necesita fuente de terceros ]
1987 también marcó la introducción del producto AppleShare , un servidor de archivos dedicado que se ejecutaba 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 era el tercer sistema operativo de red a finales 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 Office para Macintosh, que se habían basado en un dispositivo servidor de archivos dedicado.
En 1989 se lanzó un rediseño significativo como AppleTalk Phase II . En muchos sentidos, la Fase II puede considerarse un esfuerzo por hacer que la versión anterior (nunca llamada Fase I) sea más genérica. Las LAN ahora podían 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 podría crear una zona de "Impresoras" que enumeraría todas las impresoras de una organización, o se podría querer colocar ese mismo dispositivo en la zona del "segundo piso" para indicar su ubicación física. La Fase II también incluyó cambios en los protocolos de interconexión de redes subyacentes para hacerlos menos "conversadores", lo que anteriormente había sido un problema grave en las redes que conectaban 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. Estos incluyeron actualizaciones de EtherTalk y TokenTalk, software AppleTalk y hardware LocalTalk para IBM PC , EtherTalk para el sistema operativo A/UX de Apple que le permite usar LaserWriters y otros recursos de red, y los productos Mac X.25 y MacX .
Ethernet se había vuelto casi universal en 1990 y era hora de integrar Ethernet en las 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 único puerto en la parte posterior de la computadora en el que el usuario podía conectar un adaptador para cualquier sistema de cableado determinado. Este sistema FriendlyNet se basó en la interfaz de unidad de conexión estándar de la industria o AUI, 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 las computadoras Quadra 700 y Quadra 900 y se usó 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.
Cuando 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 del Power Macintosh G3 y el PowerBook G3 .
Desde el comienzo de AppleTalk, los usuarios querían conectar 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). Kinetics comercializó SEAGATE 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 Columbia AppleTalk (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 a 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 muchas Mac equipadas con LocalTalk. Pronto se hizo común incluir soporte para MacIP en los puentes LocalTalk-to-Ethernet. [26] MacTCP no se convertiría en una parte estándar del Classic Mac OS hasta 1994, [27] momento en el que también admitía SNMP y PPP .
Durante algún tiempo a principios de la década de 1990, Mac fue el cliente principal en Internet en rápida expansión. [ cita necesaria ] Entre los programas más conocidos y de uso generalizado se encuentran 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, las Mac tenían entre 2 y 3 veces más clientes conectados a Internet que cualquier otra plataforma, [30] [ se necesita fuente de terceros ] a pesar de la relativamente pequeña participación de mercado general de microcomputadoras.
A medida que el mundo pasó rápidamente a IP para usos LAN y WAN, Apple se enfrentó a 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 máquinas basadas en PowerPC . Esto llevó a los esfuerzos de Open Transport , que reimplementaron MacTCP y AppleTalk en una base de código completamente nueva adaptada del estándar Unix STREAMS . Las primeras versiones tuvieron problemas y no se estabilizaron durante algún tiempo. [31] En ese momento, Apple estaba inmersa en sus esfuerzos de Copland , finalmente condenados al fracaso.
Con la compra de NeXT y el posterior desarrollo de Mac OS X , AppleTalk era estrictamente un sistema heredado. Se agregó soporte a Mac OS X para brindar soporte para una gran cantidad de dispositivos AppleTalk existentes, en particular impresoras láser y archivos compartidos, 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. La compatibilidad con 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, más tarde rebautizado como Bonjour .
A partir de 2020, la compatibilidad con AppleTalk se eliminó por completo del soporte heredado con macOS 11 Big Sur.
El diseño de AppleTalk siguió rigurosamente el modelo OSI de capas de protocolo. A diferencia de la mayoría de los primeros sistemas LAN , AppleTalk no se creó utilizando el sistema arquetípico Xerox XNS . 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 diferenciación clave de AppleTalk fue que contenía dos protocolos destinados a hacer que el sistema fuera completamente autoconfigurable. 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 en otros sistemas existían sistemas similares a AARP, como 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 de enlace local ) 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 podría causar problemas a medida que nuevos nodos buscaban direcciones libres, la adición de un enrutador podría reducir la "charla". Juntos, AARP y NBP hicieron de AppleTalk un sistema de red fácil de usar. Se agregaron nuevas máquinas a la red conectándolas y, opcionalmente, dándoles un nombre. Las listas de NBP fueron examinadas y mostradas por un programa conocido como Selector que mostraría una lista de máquinas en la red local, divididas en clases como servidores de archivos e impresoras.
Una dirección AppleTalk era una cantidad de cuatro bytes. 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, sólo el número de red requirió configuración, ya que se obtuvo de un enrutador. Cada nodo eligió dinámicamente su propio número de nodo, de acuerdo con un protocolo (originalmente el Protocolo de acceso al enlace 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, se reservaron algunos números conocidos para propósitos especiales específicos del propio protocolo AppleTalk. Aparte de estos, se esperaba que todos los protocolos a nivel de aplicación utilizaran números de socket asignados dinámicamente tanto en el extremo del cliente como en el 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 también podían ser lo suficientemente largos para minimizar la posibilidad de conflictos.
A medida que los nombres de 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 estaba completamente separado del nombre de la máquina misma. Por lo tanto, los servicios podían trasladarse a una máquina diferente y, siempre que mantuvieran el mismo nombre de servicio, no había necesidad de que los usuarios hicieran nada diferente para continuar accediendo al servicio. Y la misma máquina podría albergar cualquier cantidad de instancias de servicios del mismo tipo, sin conflictos de conexión de red.
Compare esto con los registros A en el DNS , en los que un nombre se traduce como 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 utilizar un nombre de máquina particular para acceder a un servicio en particular, su acceso se interrumpirá cuando el servicio se mueva a una máquina diferente. Esto se puede mitigar en cierta medida insistiendo en el uso de 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 dicha convención. Algunos protocolos más nuevos, como Kerberos y Active Directory, utilizan registros DNS SRV para identificar servicios por nombre, lo que se acerca mucho más al modelo AppleTalk. [ ¿ investigacion original? ]
El Protocolo de resolución de direcciones AppleTalk (AARP) resuelve las direcciones AppleTalk para vincular direcciones de capa. [36] Es funcionalmente equivalente a ARP y obtiene 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 sonda AARP solicitando una dirección de red, con la intención de recibir respuesta de controladores como enrutadores. Si no se proporciona ninguna 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 a 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 ser necesarios varios intentos antes de encontrar una dirección libre, por lo que, por motivos de rendimiento, la dirección exitosa se registra en la NVRAM y se utiliza como dirección predeterminada en el futuro. Esto significa que en la mayoría de las configuraciones del mundo real donde se agregan unas pocas máquinas a la vez, solo se necesitan uno o dos intentos antes de que la dirección se vuelva constante.
El AppleTalk Data Stream Protocol (ADSP) fue una adición comparativamente tardía al conjunto de protocolos AppleTalk, realizada cuando quedó claro que se necesitaba un transporte orientado a la conexión confiable de estilo TCP . Las diferencias significativas con respecto a TCP fueron las siguientes:
El Apple Filing Protocol (AFP), anteriormente AppleTalk Filing Protocol, es el protocolo para comunicarse con los servidores de archivos AppleShare . Construido sobre el protocolo de sesión AppleTalk (para 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 bidireccional de números aleatorios) 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 transacciones AppleTalk (ATP), que a su vez fue la base de AFP. Proporcionó servicios básicos para solicitar respuestas a comandos arbitrarios y realizar consultas de estado fuera de banda. También permitió al servidor enviar mensajes de atención asincrónicos al cliente.
El protocolo de transacciones AppleTalk (ATP) fue el protocolo de nivel de transporte confiable original para AppleTalk, construido sobre DDP. En el momento en que se estaba desarrollando, se consideraba que un protocolo orientado a la conexión completo y confiable como TCP era demasiado costoso 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 eliminar conexiones.
Un paquete de solicitud ATP podría recibir respuesta de hasta ocho paquetes de respuesta . Luego, el solicitante envió un paquete de confirmación que contenía una máscara de bits que indicaba cuál de los paquetes de respuesta recibió, para que el respondedor pudiera retransmitir el resto.
El ATP podrí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 mantuvo una copia de los buffers de respuesta en la memoria hasta la recepción exitosa de un paquete de liberación del solicitante, o hasta que transcurriera un tiempo de espera. De esta manera, podría responder a solicitudes duplicadas con el mismo ID de transacción reenviando los mismos datos de respuesta, sin volver a realizar la operación real.
El Protocolo de entrega de datagramas (DDP) era el protocolo de transporte independiente del enlace de datos de nivel más bajo. Proporcionó un servicio de datagramas sin garantías de entrega. Todos los protocolos a nivel de aplicación, incluidos los protocolos de infraestructura NBP, RTMP y ZIP, se crearon sobre 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 Name Binding Protocol (NBP) era un sistema dinámico y distribuido para gestionar nombres AppleTalk. Cuando un servicio se iniciaba en una máquina, registraba un nombre elegido por un administrador humano. En este punto, NBP proporcionó un sistema para verificar que ninguna otra máquina hubiera registrado ya el mismo nombre. Más tarde, cuando un cliente quería acceder a ese servicio, utilizaba NBP para consultar las máquinas y encontrar ese servicio. NBP proporcionó navegabilidad ("¿cuáles son los nombres de todos los servicios disponibles?"), así como la capacidad de encontrar un servicio con un nombre particular. [36] Los nombres eran legibles por humanos, contenían espacios y letras mayúsculas y minúsculas, e incluían soporte para búsqueda.
El AppleTalk Echo Protocol (AEP) era un protocolo de capa de transporte diseñado para probar la accesibilidad de los nodos de la red. [36] AEP genera paquetes que se enviarán al nodo de red y se identifica en el campo Tipo de un paquete como un paquete AEP. El paquete se pasa primero al DDP de origen. Una vez identificado como un paquete AEP, se reenvía al nodo donde el DDP examina el paquete en el destino. Una vez que el paquete se identifica como un paquete AEP, se copia y se modifica 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 la impresora (PAP) era la forma estándar de comunicarse con las impresoras PostScript . Fue construido sobre ATP. [36] Cuando se abrió una conexión PAP, cada extremo envió al otro una solicitud ATP que básicamente significaba "envíame más datos". La respuesta del cliente al servidor fue 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 "enviar más datos". Este uso de ATP proporcionó un control automático del flujo ; cada extremo solo podía enviar datos al otro extremo si había una solicitud ATP pendiente a la que responder.
PAP también proporcionó consultas de estado fuera de banda, manejadas por transacciones ATP separadas. Incluso mientras estaba ocupado atendiendo un trabajo de impresión de un cliente, un servidor PAP podía continuar respondiendo a solicitudes de estado de cualquier número de otros clientes. Esto permitió que otros Macintosh en la LAN que estaban esperando imprimir mostraran mensajes de estado que indicaban que la impresora estaba ocupada y en qué trabajo estaba ocupada.
El Protocolo de mantenimiento de la 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 a qué distancia pensaba que estaban.
El Protocolo de información de zona (ZIP) era el protocolo mediante el cual los números de red 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 si bien era necesario asignar un número de red a una sección topológicamente contigua de la red, una zona podía incluir varias porciones diferentes no contiguas de la red.
La implementación inicial de hardware predeterminada para AppleTalk fue un protocolo serie de alta velocidad conocido como LocalTalk que utilizaba los puertos RS-422 integrados de Macintosh a 230,4 kbit/s. LocalTalk utilizó una caja divisora en el puerto RS-422 para proporcionar un cable ascendente y descendente 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 de 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 máquinas PC eran tales que era común que las Mac fueran las únicas computadoras personales conectadas en red en una oficina. Otras computadoras más grandes, como las estaciones de trabajo UNIX o VAX, normalmente se conectarían en red a través de Ethernet.
También estaban disponibles otras implementaciones físicas. Un reemplazo muy popular para LocalTalk fue PhoneNET , una solución de terceros de Farallon Computing, Inc. (rebautizada como Netopia , adquirida por Motorola en 2007) que también usaba el puerto RS-422 y era indistinguible de LocalTalk en cuanto a los controladores del puerto LocalTalk de Apple. estaban preocupados, pero se toparon con cableado telefónico estándar muy económico con conectores modulares de cuatro hilos y seis posiciones , los mismos cables que se utilizan para conectar teléfonos fijos. Dado que utilizaba el segundo par de cables, los dispositivos de red podían incluso conectarse a través de tomas telefónicas existentes si no hubiera una segunda línea. Anticipando los concentradores y conmutadores de red actuales, Farallon proporcionó soluciones para que PhoneNet se usara en configuraciones de estrella y de bus , con conexiones en estrella pasivas (con los cables telefónicos simplemente puenteados entre sí en un punto central) y en estrella activa con "PhoneNet". Hardware del concentrador Star Controller". En una configuración en estrella, cualquier problema de cableado solo afectaba a un dispositivo y los problemas eran fáciles de identificar. El bajo costo, la flexibilidad y la sencilla solución de problemas de PhoneNet hicieron que fuera la opción dominante para las redes Mac a principios de los años 1990.
Los protocolos AppleTalk también llegaron a ejecutarse sobre capas físicas Ethernet (primero coaxial y luego 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 a lo largo de la década de 1990. Además de AppleTalk y TCP/IP , cualquier red Ethernet también podría transportar simultáneamente otros protocolos como DECnet e IPX .
Cuando se introdujo AppleTalk por primera vez, la plataforma informática de oficina dominante era la PC compatible con MS-DOS. Apple introdujo la tarjeta AppleTalk PC Card a principios de 1987, lo que permitía a las PC unirse a redes AppleTalk e imprimir en impresoras LaserWriter. [39] Un año después, se lanzó AppleShare PC, que permite a las PC acceder a los servidores de archivos AppleShare. [40]
El sistema de red MS-DOS "TOPS Teleconnector" [41] sobre el sistema AppleTalk permitió a las PC MS-DOS comunicarse a través del hardware de red AppleTalk; comprendía una tarjeta de interfaz AppleTalk para la 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 exclusiva para PC, permitió la comunicación entre PC y Mac con el software TOPS instalado. (Las Mac sin TOPS instalado podían usar la misma red pero solo para comunicarse con otras máquinas Apple). El software TOPS de Mac no igualaba la calidad del software de Apple ni en facilidad de uso ni en robustez y ausencia de fallas, pero el software DOS era relativamente simple de usar en términos de 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 archivos nativos o servidores de impresión para computadoras Macintosh e imprimir en impresoras LocalTalk a través de la red.
Los sistemas operativos Windows Server admitían AppleTalk desde Windows NT hasta Windows Server 2003 . Miramar incluyó AppleTalk en su producto PC MacLAN, que CA descontinuó en 2007. GroupLogic continúa combinando su protocolo AppleTalk con 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 esencialmente de un conjunto de servidores de archivos e impresión que se ejecuta en una amplia gama de plataformas diferentes.
Además, la Universidad de Columbia lanzó el paquete Columbia AppleTalk (CAP), que implementó el conjunto de protocolos para varios tipos de Unix, incluidos Ultrix , SunOS , BSD e IRIX . Este paquete ya no se mantiene activamente.