[gull] serveur tcp et udp clients multiple

[Yann Sagon]

Le 7 janvier 2009 09:22, Daniel Cordey <dc at mjt.ch> a écrit :
> On Tuesday 06 January 2009, Yann Sagon wrote:
>
>>
>>                     -------------------------------
>>             1x UDP  |                             | n x TCP
>>              ====>  |                             | ===>
>>                     | copie du message            | ===>
>>                     |                             |...
>>                     |                             | ===>
>>                     -------------------------------
>
> Pourrais-tu elaborer un poil plus ?

Salut, j'ai donné plus de détails sur les autres réponses. J'espère
que c'est plus clair.

> Y-t-il un protocole d'application au-dessus de tout cela,
> qui te permette de recomposer le/les message dans l'ordre.

Un minimum.

> De
> plus, il n'est pas certain que les librairies PHP soient thread-safe. Or, ceci
> peut poser de gros probleme !

Oui, c'est sûr.

>> Vu que c'est à destination d'une machine LAMP, j'ai premièrement
>> commencé par le coder en php avec des fork pour prendre en compte les
>> multiples clients tcp. Je communique entre les fork par des pair de
>> socket. ça fonctionne mais c'est très bricolage.
>
> C'est une solution qui en vaut une autre et ce n'est pas forcement une
> mauvaise solution. Tout depent des contraintes de performance, de
> fonctionalite et de souplesse.

Pas besoin de grosses performances. Quelques clients (au max une 10
aine) et données "courtes" (moins de 100 octets par paquet UDP envoyé
au maximum chaque 100 ms)
>
>> J'aimerais le re faire en QT pour qu'il soit éventuellement portable.
>

Qt me plait bien (donc choix totalement irrationel:))

> Pourquoi specialement Qt ? Ne serait-ce pas plus facile de developper une
> librairie et de definir un API non dependent d'une autre grosse librairie ?
>

C'est juste une petite application pour une démo. Elle doit être
utilisable facilement et ne va pas évoluer.

>
> Haaaaaa les shared memory :-) Je ne connais pas l'implementation des shared
> memory de Qt, mais j'espere que cela utilise plutot les "memory maped files",
> sinon on risque de gros probleme de resilience dans les phases transitoires
> (cration/destruction de thread, persistance de l'information, etc.).
>
Aucune idée. Mais je ne vais pas utiliser cette solution, elle est
inutile avec des threads comme l'a fait remarquer Marc.

> Je ne crois pas que les threads soient indispensables et on peut tres bien
> avoir un process d'envoi (UDP) avec N process independants, lances par
> inetd...

Pas très portable ça..

> A mon avis, le seul moyen de developper quelque chose qui fonctionne bien (en
> etant meme plus performant) est de le developper en C/C++.

Qt fera donc l'affaire! Je peux utiliser les signals and slots entre
les thread (ce que je ne savais pas.. )

> La seulement, on
> sait si les libriaries sont thread-safe ou pas. Ignorer le probleme des
> thread-safe, lorsque l'on veut gerer des shm/mmap et des semaphores, revient a
> se tirer dans le pied avec deux pistolet tout en ayant la corde au cou :-)
>
Ca doit faire mal:)

A+