2011-11-24 9 views
19

Trabajo en implementar compatibilidad con IPv6 para varias aplicaciones, pero me pregunté para qué son estos 2 campos. Hay muy pocas preguntas sobre esto aquí, así que no estoy seguro de haberlo hecho bien.Agregando soporte para IPv6 en aplicaciones cliente/servidor IPv4 - ¿campos sin6_flowinfo y sin6_scope_id?

  • Acerca de ID de ámbito (sin6_scope_id) - bueno, Q1, Q2, Q3 y Q4 me dio idea acerca de la ID de ámbito y creo que lo entiendo. Por lo tanto, tendré que agregar un parámetro de configuración más para que el identificador de alcance sea configurable. (Decidí agregar esto aquí, en caso de que alguien esté interesado en esto). En pocas palabras, la identificación del osciloscopio es necesaria para determinar de manera única cuál es el dispositivo que debe manejar el tráfico, porque puede haber varias interfaces, con la misma IP, pero con una ID diferente (¿interfaz?). Hasta aquí todo bien.
  • Pero ¿y el "flujo de información" (sin6_flowinfo)
    • ¿Qué es para? No pude encontrar nada interesante sobre eso. Leí el RFC pero no me ayudó en absoluto.
    • ¿Hay algunos valores posibles para sin6_flowinfo (como - varios valores, como indicadores, que significan algo), o es como el sin6_scope_id - puede haber algún valor, dependiendo del dispositivo, estoy tratando de conectarme?
    • Debería preocuparse por ello en absoluto, o que mis dejarlo 0 (como en Beej's Guide to Network Programming. Y sí, lo he intentado, funciona, pero no estoy seguro si funciona sólo en este caso (si depende de alguna configuración de red), o siempre funcionará, si está configurado en 0?
    • O, tal vez, debería hacerlo configurable, quiero decir - agregar una opción de configuración más y dejar que el usuario defina su valor?
    • google -ing "sin6_flowinfo" me da definiciones de estructura y páginas man, nada útil sobre este campo. ¿Alguna fuente interesante? (Comprensible ... no RFC: D)

EDITAR: Bueno, después de la respuesta @glglgl 's y después de la indirecta, que sin6_flowinfo puede ser obsoleta, encontré algunas fuentes interesantes: RFC: IPv6 Flow Label Specification, IETF draft: Flow Label as Transport-Layer Nonce, Practical guide for solaris y wikipedia.
El campo no es obsoleto (o no pude encontrar esas fuentes, que confirma esto), pero parece 0 como valor es lo suficientemente bueno.

+1

Quité el comentario sobre votos a la baja - es una pregunta perfectamente buena, no te preocupes por eso. – caf

Respuesta

6

La mejor manera de hacerlo es usar getaddrinfo().

pseudo código:

struct addrinfo *restrict hints = { .ai_family = AF_UNSPEC, .ai_socktype = SOCK_STREAM }; 
struct addrinfo * res, r; 
if (0 == getaddrinfo("foo.bar.baz", "http", &hints, &res)) { 
    for (r=res; r; r=r->ai_next) { 
     sock = socket(r->ai_family, r->ai_socktype, r->ai_protocol); 
     connect(sock, r->ai_addr, r->ai_addrlen); 
     if error: continue 
     break 
    } 
} 
freeaddrinfo(res); 

Esto tomará la preocupación por sin6_scope_id de usted; que normalmente es 0, excepto si tiene direcciones locales de enlace como fe80::1234:56ff:fe78:9abc%eth2. Este eth2 se convierte al identificador de ámbito correcto.

sin6_flowinfo es obsoleto (AFAIK) y por lo tanto establecido en 0 en su resultante struct addrinfo's ai_addr.

+0

Sí, conozco esta opción y la he agregado, pero quiero agregar la posibilidad de configurar manualmente cada opción. Y me quedé en 'sin6_flowinfo'. Leeré el enlace sobre 'sin6_flowinfo' más tarde, pero si está obsoleto y puedo dejarlo' 0', sería perfecto. Gracias una vez más :) –

+0

Bueno, no pude encontrar una fuente relevante, que dice, es obsoleta, pero estoy de acuerdo con el valor '0'. Encontré algunos enlaces interesantes, que publicaré en mi pregunta, para aceptar los tuyos, en lugar de publicar los míos. Gracias por la ayuda. –

+1

@KirilKirov Tienes razón: es todo lo contrario de lo obsoleto: aún no saben exactamente qué hacer con él ;-) – glglgl

Cuestiones relacionadas