En Off hemos implementado una nueva abstracción de IPC denominada Portal que soporta tanto transferencias protegidas de control como envío de mensajes asíncronos y síncronos, invocación distribuida (empleando bien protocolos genéricos, bien protocolos específicos para cada aplicación) y reubicación entre distintos nodos. Además, los portales permiten múltiples invocaciones simultaneas a través del mismo portal. En pocas palabras, cada portal en Off representa un punto de acceso direccionable desde cualquier nodo en la red.
Una vez creado, un portal lleva asociado un manejador que puede reemplazarse posteriormente. El manejador viene definido principalmente por dos elementos:
Los portales implementan dos mecanismos básicos que constituyen dos formas de invocación distintas y pueden emplearse para la realización de distintos modelos de IPC.
en un servidor. La ejecución del cliente se bloquea
durante el tiempo mínimo necesario para iniciar el envío del mensaje
(hasta que el estado del servidor ha sido alterado para que él mismo
invoque al manejador del portal en el caso de envíos locales y hasta
que el servidor que implementa el protocolo de transporte en red ha
sido invocado en el caso de envíos remotos). Podríamos considerar
que la invocación es no-bloqueante puesto que el envío puede
proseguir mientras el cliente está ya ejecutando el código presente
tras la invocación del portal.
Nótese que estamos empleando ``mensaje'' para referirnos a la información transferida en la invocación. Los mensajes que realmente transfieran los usuarios del sistema de portales no tienen por que ir contenidos en estos ``mensajes'' de los que hablamos continuamente. Por ejemplo, el ``mensaje'' que transfiere el portal podría ser una referencia a un buffer de memoria compartida que contuviese el mensaje transferido por el usuario, cosa que podría hacerse para implementar protocolos de comunicaciones con cero-copias (sin copiar repetidamente los mensajes en su curso entre el hardware de comunicaciones y las aplicaciones) como los ya existentes para TCP en algunos sistemas como Solaris [41].
Los portales permiten la realizacion de esquemas de objetos pasivos
[73] gracias al segundo mecanismo. No obstante
hay que tener en cuenta que también pueden utilizarse para implementar
un modelo de objetos activos (mediante cualquiera de los mecanismos).
Ambos mecanismos se emplean también para enviar excepciones,
interrupciones y otros eventos a las aplicaciones. Aunque veremos más
adelante ambos casos en más detalle, se trata sencillamente de
convertir la ocurrencia de uno de estos sucesos en invocación de
portales (para ello basta que el 
kernel invoque el portal adecuado tras
el suceso considerado).
Salvo por detalles de sincronización entre el cliente y el servidor, ambos mecanismos se diferencian principalmente en el proceso de elección del shuttle sobre el que ejecutará el manejador del servidor como resultado de la invocación del portal. En el primer caso (envío asíncrono), el sistema activa el manejador de portal asíncronamente en un shuttle pre-especificado; este shuttle podría estar ejecutando tareas de ``mantenimiento''en el servidor antes de la invocación del portal, podría también estar bloqueado esperando la invocación del portal. En el segundo caso (envío síncrono), el shuttle origen se emplea para ejecutar el código del manejador; no es necesario disponer de un shuttle preexistente en el servidor esta vez (aunque si se requiere una pila disponible para que el shuttle que realiza la invocación pueda ejecutar en el servidor).
Para comprender como operan los portales es conveniente ver la arquitectura del sistema de portales en su conjunto. En la figura 3.17 podemos ver todos los elementos involucrados:
Figure 4.2: Elementos involucrados en el sistema de portales
kernel llama al servicio de transporte identificado por el
portal de transporte designado por la aplicación. Este
portal no es otra cosa que el designado por la aplicación para
gestión de las excepciones enviadas por el kernel cuando es preciso
redirigir una llamada al sistema a un nodo remoto. Podemos
imaginar al servicio de transporte como un intermediario
(especificado por la aplicación) entre el kernel local y el remoto
en aquellas invocaciones de portal destinadas a otros nodos.
En realidad, este servicio de transporte deberá incluir también un protocolo de localización de portales. El servidor deberá pues esperar peticiones de localización de portales y ayudar a procesarlas como vimos en el apartado 2.1.7.