Discussion :

[loup_precaire]

Salut à tous,

Je viens poster pour avoir un avis sur les réseaux sachant que ce n'est pas du tout mon domaine.
Je fait parti d'un projet qui consiste en un réseau local de 3 machines : un PC d'acquisition qui va acquérir des images et les envoyer par réseau à un PC de traitement qui va traiter ces images pour envoyer le résultat à un 3e PC.

Sachant que le PC d'acquisition peut acquérir jusqu'à 360 images de 64Mo chacune et que l'on aimerait que le transfert se passe le plus rapidement possible, quelles technologies/protocoles me conseillez-vous pour la partie réseau?

Me basant sur mes connaissances très limités, je pensais utiliser des sockets udp en partant du principe que les tailles et infos images sont déjà connus donc inutile d'envoyer les infos bitmaps, on peut les paramétrer ds les softs, on enverrai donc que les données bruts des images mais il faudrait pouvoir numéroter chaque paquet pour etre sûr de la reconstruction sur le 2e pc.

Est-ce que l'udp est le meilleur choix si l'on reste sur de l'ethernet?

Quelle autres possibilité a-t-on ? je suis ouvert à tout, même à des solutions payantes.

Pour info, le PC d'acquisition serait sous windows 32bits et le PC de traitement sous windows 64bits.

merci bcp de vos réponses

[screetch]

La premiere chose a faire serait de compresser les données avant de les envoyer pour réduire la bande passante
Ensuite, UDP est possible si tu ajoutes a chaque paquet (morceau d'image) que tu envoies le numéro, et que tu peux redemander les paquets manquants. mais je ne suis pas certain que cela améliorera comparé a TCP

[loup_precaire]

En fait, is j'ai choisi UDP c pour sa rapidité et parce que s'il manque un paquet, ce n'est pas bien grave, j'ai juste besoin de savoir qu'il y en a un qui manque et où d'où la numérotation des paquets, mais je n'ai pas besoin de les redemander, je remplace juste le paquet par du noir sur l'image. Après s'il s'avère qu'il y a beaucoup de perte, je serais contraint de passer au TCP mais je pnes que ça devrait aller sur un réseau local de 3 ordi.

En ce qui concerne la numérotation des paquets, je me demandais si c'était possible d'utiliser un champ de l'entête UDP, comme par exemple le numéro de port source ?
Car si j'envoi le numéro avec les données, je serais obligé de faire des copies de l'image. Par exemple si je peux mettre la numérotation dans l'entete, je peux envoyer l'image en ne gérant qu'un pointeur sur les données de l'image. Sinon, je dois copier la partit à envoyer dans un autre buffer auquel je rajoute un numéro avant de l'envoyer et au final, je me retrouve à faire une copie entière de l'image pour l'envoi.
Est-ce que quelqu'un saurait si c possible de modifier comme on veut l'entête UDP? (et récupérer l'info modifiée de l'autre côté de la socket?)

[3DArchi]

Dans un réseau local, tu auras probablement peu de pertes. Ensuite UDP ou TCP : franchement au vu de la taille des données à envoyer, je pense que le protocole aura peu d'influence sur le débit; idem si tu rajoutes un p'tit quelque chose au dessus de TCP pour gérer ton flux.
Travaille plutôt sur les possibilités de compressions. Une autre piste est d'adapter tes traitements pour qu'ils s'appuient sur un flux et non sur l'intégralité des données.

[Twindruff]

Je crois vraiment pas que tu gagnes grand chose à recréer du TCP en UDP, faudrait voir avec un ptit bench.
Tu peux aussi acheter des carte réseau 1Gbps si t'as que des 100Mbps (+switch), ça coûte pas grand chose. Dans ce cas là ça serait tes disques dur qui limiteraient la vitesse de transfert.

[loup_precaire]

désolé, j'ai été malade pendant 2 jours, j'ai pas pu rebondir sur vos suggestions plus tot.

Twindruff :
j'avais déjà l'intention de prendre des cartes réseau 1Gbps mais je n'ai pas pensé que les disques dur limiteraient la vitesse de transmission. Merci, je choisirai le dur en fonction.

3DArchi:
ça change quoi exactement de travailler avec des flux? je ne susi pas sûr de voir la différence.

[3DArchi]

ça change quoi exactement de travailler avec des flux? je ne susi pas sûr de voir la différence.

Soit ton algo est basé sur le fait que toutes les données sont accessibles à un instant t (1), soit ton aglo peut traiter les données au fur et à mesure (2).
Par exemples (qui n'ont rien à voir avec ton problème) :
Pour calculer une moyenne sur a0, a1,...an.
Soit tu considère que tu as toutes les infos d'un coup et tu fais moyenne = somme(ai)/n -> approche (1)
Soit tu considère calcule ta moyenne comme ça m0=0,n=0, puis m(n+1)=(n*m(n) +a(n+1))/(n+1). Cet algo n'a pas besoin de toutes les données et à chaque fois qu'une nouvelle donnée arrive, tu réactualise ta moyenne.
Les deux algos sont équivalents mathématiquement mais pas informatiquement (propagation des erreurs).

Un autre exemple : pour copier un fichier (c'est un exemple !)
-> (1) soit tu lis tout le fichier et tu l'écris tout dans un seul buffer
-> (2) tu lis bloc par bloc et recopie bloc par bloc. Cet algo n'a pas besoin d'information sur ce qui arrive par la suite.

J'espère que je me suis fait comprendre et que je n'aie pas été trop confus...

[loup_precaire]

Oui ok, je vois ce que tu veux dire.
En fait les images qu'on envoi par réseau s'obtiennent d'un seul bloc, on ne peut pas les recevoir au fur et à mesure de l'acquisition donc, non, ce n'est pas du streaming.

En tout cas, merci pour tous pour toutes vos infos, elle m'ont aidées à me diriger. Là, je crée une appli de test à partir de laquelle je ferais des tests afin de voir ce qui est le plus intéressant dans les conditions d'utilisation.