[gull] serveur tcp et udp clients multiple

[Yann Sagon]

Le 6 janvier 2009 19:04, Félix Hauri <felix at f-hauri.ch> a écrit :
> Bonjour,
>
> On Tue, Jan 06, 2009 at 04:24:59PM +0100, Yann Sagon wrote:

> Unidirectionnel, donc?
>
Oui, par contre je me suis mal expliqué:

L'entrée UDP (listen) récupère des données envoyées depuis une autre machine.
Les n sorties TCP sont en fait également initiée par plusieurs clients
sur d'autres machines également.
C'est donc simplement un port en TCP qui est également en listen et
qui fait un accept (nouveau thread ou process)

> A priori, tu peux le faire en shell, avec un spécaliste des connexions
>  réseau comme netcat, des fifos et la commande de multiplexage ``tee'':
>   $ for ((i=1;i<=N;i++));do
>      mkfifo /tmp/fifo$i
>      nc tcp_ip_$i tcp_port </tmp/fifo$i &
>      done
>   $ nc -u udp_ip udp_port | tee /tmp/fifo1 /tmp/fifo2 ... /tmp/fifoN
> )
>

Oui, j'avais commencé par regarder ce type de solution, mais je ne
vois pas comment faire pour qu'un nouveau client tcp puisse se
connecter.

>> ... Je communique entre les fork par des pair de socket.
>> ça fonctionne mais c'est très bricolage.
> Un socket est en principe bi-directionnel. D'autre part, si tu parles
> de paires, c'est que tu utilises des connexions bi-directionnelles!?
>
J'utilise des socketpairs par facilité. En fait c'était pour notifier
le process tcp "listen" que le client c'est déconnecté. Et également
pour recevoire les données depuis le process UDP


>
>> ... autrement que en faisant du polling.
> Tout dépend de ce que tu veux faire exactement...
> ``Transformer'' de l'udp en tcp, à la volée, ce n'est pas anodin.
> (controle d'erreur, répetitions, connexions, state ...)
>
Les données que je reçoit en udp peuvent être perdues, répétées etc,
il n'y a pas d'incidence sur le fonctionnement de l'application. Il
n'y a pas besoin de "state" non plus.