🚀 go-pugleaf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

En/na Oscar Garcia ha escrit:

> No hombre. Con socket creas las estructuras asociadas al socket que
> est�s creando. Para conectarte a una m�quina remota no necesitas un
> "connect", ni siquiera un "bind" (que ser�a necesario en caso de que
> no quieras que el SO elija por t� ip y puerto local).

Te recurdo que me intento es 'emular' un protocolo orientado a conexi�n.
A�n as� de tu comentario deduzco que con un bind() y luego un connect()
puedo elegir direcci�n y puerto local y remotos tanto en UDP como en
TCP. Se puede as�?

> Con UDP como cliente basta con rellenar los campos de la estructura
> socket y en sendto y recvfrom dar como par�metro una estructura que
> ser� rellenada con los datos del host remoto que nos transmite tanto
> por nosotros mismos para indicar al host con el que queremos
> comunicarnos.

Si ya lo s�, pero uso el connect() precisamente por qu� me garantiza que
la capa UDP s�lo leear� paquetes enviadados des del extremo al que me he
'conectado' aunque UDP no sea orientado a conexi�n. Eso me ahorra tener
que usar recvfrom() o sendto() por ejemplo.

> Pero deber�as implementar una capa en tu protocolo que abstraiga los
> m�todos bind, connect, etc usando paquetes UDP.

Y as� lo he echo.

> Lo normal es enviar un paquete UDP solicitando la conexi�n y que tu
> aplicaci�n la permita o la rechace no sin antes pasarle mediante un
> callback a la aplicaci�n interesada que dicha conexi�n se ha
> producido.

(Supongo que con 'callback' indicas algo tipo el SYN+ACK del TCP, que es
similar a lo que yo hago.)

Precisamente en este punto es donde tengo problemas:

Una vez el servidor ha acceptado (y notificado al cliente) la
'conexi�n', el cliente ya puede transmitir y recibir sin problemas, ya
que el socket ya est� "conectado" al servidor.

Pero el servidor en ese momento s�lo dispone de un socket UDP associado
localmente mediante bind() que, aqu� mi problema, RECIBE DE QUALQUIER
CLIENTE. Por lo tanto necesito un m�todo para distinguir diversos
clientes (flujos), y como muy bien apunta I�aki, UDP no tiene concepto
de flujo por lo que me las debo apa�ar yo.

Mi idea era intentar emular el accept() de TCP m�s o menos as�:

- - Una vez acceptada la conexi�n el servidor creo un nuevo socket
- - Con bind() lo associo al puerto local donde doy servicio (que �s por
d�nde el cliente me enviar� datagramas).
- - Con connect() lo associo al cliente que ha pedido la conexi�n. Aunque
UDP no �s orientado, eso me garantiza que S�LO RECIBIR� DATAGRAMAS DE
ESE CLIENTE (man dixit)



> Debes crearte una estructura a nivel de tu aplicaci�n que guarde todos
> los valores de ambos extremos una vez que se haya terminado el proceso
> de establecimiento de conexi�n. Esto implica que todo lo tendr�s
> previamente almacenado en memoria (los sockaddr_in del otro extremo,
> por ejemplo).

Ya tengo esa estructura, s�lo que hasta el momento intentaba evitar
tener que almacenar esa informaci�n, pero veo que ya va siendo hora de
que toque de pies al suelo y lo haga.

> Entonces estar�as usando TCP y no UDP.

No, la llamada socket() especifica el tipo de protocolo via SOCK_DGRAM o
SOCK_STREAM, connect() y bind() no hacen nada al respecto. (Mira las
p�ginas de man)

> A ver. Eso es posiblemente porque has hecho un bind y has ocupado un
> puerto local y/o ip local para enviar datos, de modo que no se puede
> usar ese mismo puerto para enviar m�s datos.

Ten�a entendido (quiz� me equivoco) que el sistema identifica una
conexi�n/socket por la tupla
direcci�n-local:puerto-local/direcci�n-remota:puerto-remoto, por lo que
cre�a que podr�a hacer el bind() a�n y ya tener un socket en ese puerto,
pero se queja con el error "Address already in use", por lo que debo
destimar este enfoque.

> En UDP se especifica en el sendto directamente.

En el sendto() no hay problema: YO digo al sistema D�NDE enviar. El
problema �s con recvfrom(), el SISTEMA me dice de D�NDE he recibido,
cuando yo lo que quiero �s poder indicar-le de que direcci�n deseo recibir.

Evidentemente puedo recibir y luego "separar" el flujo seg�n la
direcci�n remota, pero esto complica mucho el c�digo. Tambi�n havia
pensado en usar MSG_PEEK, para dejar el datagrama en la cola caso de no
interessarme, per� no lo veo muy fiable para m�s intereses.

> Sinceramente no me ha quedado muy claro lo que deseas conseguir.

Lo s�

> En un principio pens� que deseas implementar (quiz� para un trabajo de
> la universidad) una capa de transporte de datos orientado a conexi�n
> haciendo uso de una capa inferior no orientada a conexi�n.

Exactamente esto!

> Si te explicas un poco mejor la verdad que lo agradeceremos.

Espero haverlo hecho, a�n as� los comentarios me han hecho ver lo que
tem�a: iba por mal camino. Pero pens� que quiz� alguien ver�a una forma
m�s simple de hacerlo.

Muchas gracias.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDsnHh4CVRFTc6wP8RAgmVAJ9/GXdFfy/dAHCcIfqO/555srOsIwCfRPid
1SY3+yUAb/tZ8ult9bv2ri8=
=XLNT
-----END PGP SIGNATURE-----