Casi la totalidad de los 
kernels existentes utilizan algún tipo de
buzón de mensajes o puerto como abstracción principal para
IPC.
Los puertos son sencillamente buzones a los que las aplicaciones pueden enviar mensajes [55, 74]. Naturalmente también es posible recibir mensajes de estos buzones.
En sistemas como Mach [55, 2] y otros
muchos, los puertos tienen capacidad de almacenamiento y retienen los
mensajes enviados que no han podido entregarse. Cuando el
almacenamiento se agota se aplica algún mecanismo de control de flujo.
Aquellas aplicaciones que no necesitan almacenamiento de mensajes
deben soportar la sobrecarga añadida por esta facilidad, puesto que no
es opcional. Las aplicaciones que desean almacenamiento de mensajes
deben adoptar la implementación suministrada por el kernel, dado que
ésta está contenida y cableada dentro del núcleo.
Hay otro inconveniente que presentan los puertos empleados comúnmente.
Éstos están fijos en un determinado nodo del sistema y no es posible
reubicarlos. La distribución de puertos suministrada en
modernos kernels suele consistir tan sólo en la posibilidad de invocar
transparentemente a puertos remotos. Como consecuencia, es
típicamente imposible ``mover'' una aplicación y los puertos por ella
servidos de un nodo a otro, con lo que es necesario emplear mecanismos
adicionales (que introducen otro nivel de sobrecarga en el sistema de
IPC) para ``reconectar'' los posibles clientes a la aplicación siempre
que ésta sufre un cambio de ubicación.
Lo que es más, en algunos casos los puertos no sólo están anclados a un nodo sino también a una aplicación concreta y no es posible que una aplicación ceda algunos puertos a otra para delegar parte de su carga de trabajo. Afortunadamente existen sistemas flexibles como Kea [169] y otros permiten la cesión o delegación de puertos--aunque, típicamente, no toleran la ``reubicación'' de los mismos.
Por último, es habitual que los kernels que incorporan puertos (salvo
honrosas excepciones como L4 [110, 109]
y otros) sólo soporten un modelo de objetos activo. Consiste éste en
múltiples aplicaciones (u objetos) que poseen uno o más flujos de
control (están activos) y se comunican entre sí mediante envío de
mensajes. Esto introduce problemas de latencia y jitters en las
implementaciones de modelos cliente/servidor. La causa es la
variabilidad que introduce la ejecución del planificador entre las
ejecuciones del cliente y del servidor.
Como sostienen algunos autores [72], los kernels
deberían soportar modelos de objetos pasivos. En el modelo de objetos
pasivos los clientes ceden su flujo de control al servidor durante la
ejecución de éste. No es necesario replanificar en cada interacción
cliente/servidor y la latencia es menor y más regular.
Los portales de Off tratan de superar los problemas arriba mencionados, como veremos a lo largo de este apartado.