2010-02-11 13 views
8

SCTP tiene soporte nativo multi-hogar que si lo entiendo correctamente redirigirá automáticamente sus paquetes a través de una NIC secundaria si la interfaz primaria se cae. Dupliqué esta funcionalidad con TCP escribiendo un deamon de enrutamiento personalizado para modificar las tablas de enrutamiento si mi NIC principal deja de funcionar. Me gustaría intentar usar SCTP en su lugar.SCTP con Multihoming como Reemplazo Sustituto para TCP

En Steven Unix Network Programming V1 3rd Edition en la página 288 se dice:

Para este ejemplo, se utiliza un servidor de uno-a-muchos estilo. Hacemos esta elección por una razón importante. Los ejemplos en el capítulo 5 pueden ser modificados para funcionar sobre SCTP con un cambio menor : modificar la llamada socket función para especificar IPPROTO_SCTP en lugar de IPPROTO_TCP como el tercer argumento. Simplemente realizando este cambio, sin embargo, no tomaría ventaja de ninguna de las características adicionales provistas por SCTP excepto multi-homing.

Ahora he intentado esto con resultados bastante pobres.

Funciono en Ubuntu 9.04 con los paquetes libsctp1, libsctp-dev y lksctp-tools instalados. He verificado con lksctp-tools que SCTP funciona correctamente.

Tomé el UNP example code y lo modifiqué como se indica más arriba en los programas ~/unpv13e/tcpcliserv/tcpserv04.c y ~/unpv13e/select/tcpcli02.c.

Este es un simple par echo server/client. El servidor funciona aparentemente escuchando, pero el cliente sale diciendo que la conexión fue rechazada. Desde netstat no soporta SCTP Solía ​​lsof -n | grep tcpserv que me mostró:

tcpserv04 6208  alice 3u  sock  0,4   33889 can't identify protocol 

Esto no parece que contar conmigo mucho más que tcpserv04 tiene algún tipo de socket abierto.

Ya había reescrito y probado el cliente TCP original en perl, así que lo cambié a sctp y pude conectarlo aunque la conexión de un archivo en stdin no funcionó por completo (se colgó a aproximadamente 2/3 del camino al recibir el eco está de vuelta).

Parece que UNP está implicando que el portar aplicaciones TCP a SCTP para aprovechar el multi-homing es trivial, pero basa este simple intento que realmente no parece ser el caso.

¿Alguien puede dirigirme a un buen tutorial o dar buenos consejos sobre cualquier programa para tener en cuenta al momento de portar aplicaciones TCP a SCTP de uno a uno para aprovechar el multi-homing?

+0

TCP también puede implementar esta forma de redundancia ---- múltiples rutas de aa b en la tabla de enrutamiento - ¿por qué molestarse? –

+0

@Hassan Syed: Porque tengo curiosidad. –

+0

has intentado capturar wireshark. Si todo está configurado correctamente, una llamada de conexión en el cliente debe desencadenar el apretón de manos de 4 vías hacia el servidor. Además, no pude encontrar el archivo del cliente (~/unpv13e/select/tcpcli02.c) del enlace que proporcionó. –

Respuesta

2

tcpcli02 intenta conectarse al puerto 7, mientras que tcpserv04 escucha en el puerto 9877 (el valor predeterminado para SERV_PORT). Después de cambiar esos para que coincida, funciona para mí.

El soporte para SCTP generalmente es muy malo. A menos que controle toda la infraestructura de red entre los hosts que está tratando de conectar, no contaría con que funcione de manera confiable. Portar las aplicaciones en sí debería ser bastante sencillo, como se menciona en UNP.

+0

Creo que solo necesitaría controlar los dos puntos finales que están hablando entre sí. ¿Por qué necesitaría el control de la "infraestructura de red completa"? Ahh, supongo que todos los enrutadores en la red necesitarían tener soporte explícito para SCTP y la mayoría de las veces no? –

+1

De hecho. En teoría, los enrutadores no deberían ser un problema, ya que no inspeccionan en la capa 4. Los enrutadores en el núcleo de Internet probablemente no lo harán. Sin embargo, cuanto más se acerque al límite, más probable es que sea así. Una vez que llegue a las casillas haciendo NAPT (que se basa en mapear paquetes a puntos finales usando encabezados de capa 4), probablemente no tenga suerte, ya que seguramente solo tratarán con TCP y UDP. – fnl