UDP

aucune garantie (surtout si tu tombes dans une phase de swapp).

nouveaux mais, AMHA, ADA est un bon candidat.

faudrait s'orienter vers un autre choix, TokenRing par exemple.

te poses les questions fonctionnelles que maintenant. Tu n'as pas de cahier des charges ?

( pour l'instant : 6 sondes + 1 moteur = 7 cartes )

un moteur tombe en rade, pour faire remonter une alarme )

Des tests de quelques heures sous LAN (avec d'autres PC dessus) montrent 100 % de com correctes avec un timeout de 20 ms ( ca _marche_ aussi sous 10 ms mais avec les quelques glitchs

plus un intervalle de scrutation global de 10 ms ; soit au pire ~150 ms donc correct devant 500 ms.

Windows ( oui, je sais ... )

Je n'utilise pas TCP. Sous l'angle de la garantie de livraison des paquets,

Je m'en doutais, et surtout en UDP (TCP s'en sort bien mieux)

et au pire je pourrai toujours me replier sur du RS485,

relativement facilement sur d'autres modes de com.

dix ans et n'a pas du servir souvent ;>)

Ben, c'est bien pour cela qu'il y a des couches au dessus. C'est fou le nombre de paquets que je perd sur le net, pire que ma tete (heureusement ;>)

nouveaux mais, AMHA, ADA est un bon candidat.

rapide et la on parle de ms si j'ai bien compris (pour MS cela marche aussi, en industrie il y en a plein ;>), et le dev c'est du C standard comme tout

2 : Non, pourquoi ? A partir du moment ou tu a un trafic bi-directionnel ou a plusieurs medias tu a des risques de collision. Mais je ne vois pas le

transit des paquets, a moins bien sur de compter en secondes. Et la on est plus sur une gestion de paquets perdus que de collision. La c'et ta pile Ip

probleme tu aura des fonctions toutes faites pour cela, si tu est sous micro

box/ internet tu va faire de la translation de port, celle ci peut etre transparente bien sur.

Bref regarde la doc de tes bibliotheques et des appels de procdure de tes OS, tu doit trouver toute les reponses a tes questions.

un moteur tombe en rade, pour faire remonter une alarme )

de la sonde distance pour etre sur quelle est toujours en ligne, c'est la

d'entreprise (et je ne parle pas du web). Je n'ai jamais mis d'analyseur de trames dessus mais je suppose que cela bosse en Tcp bien sur.

liaison directe bien sur.

J'ai sans doute mal compris mais franchement si tu compte sur la redondance

;>)

le domaine de collision.

--
Sylvain

--
pas de turlututu. apres l'@robase

| un moteur tombe en rade, pour faire remonter une alarme

D'ailleurs ca me semble la moindre des choses question robustesse.

vais pas bouder mon plaisir puisque sur ce projet je ne compte pas mes heures )

que celle de l'appli, quelle serait la source d'une collision ?

alors que les variations physiques des grandeurs en cause sont lentes au point de rendre acceptable un temps T = 5 secondes.

Mais ce n'est pas une obligation.

Oui, il y a de ca, en partie.

alors que sous UDP ce sont les sockets qui s'en occupent.

donc, logiquement, la proba de collision est strictement nulle.

Mais je ne serais pas contre le fait d'y superposer aussi le send-mail,

( donc un point positif pour UDP en regard de RS485 )

Non pas le *temps* de transit ( car je peux adapter le timeout )

Yep.

C'est pas faux :o) Mais je n'aime pas trop tabler sur du code auquel je n'ai

D'accord, bien recu.

Merci pour ce feedback.

Jean-Christophe :

produire une collision ?

--
pas de turlututu. apres l'@robase

message et ensuite on verra ...

restreind (ou interdit) une tentative d'ouverture de port qui vient de

esclaves avec un maitre comme

prises rj standard ;>)

Internet, sont en contradiction avec le RT.

, et le dev c'est du C standard comme tout

--
Sylvain

tu aura un switch, si il est manageable bonjour le trafic, tu aura un routeur idem pour beaucoup surtout les box.

devient dur) le domaine de collision est bien sur unitaire mais tu aura de

voir TTL

du trafic dessus.

Bonjour Olivier,

Le Sat, 10 May 2014 09:15:00 +0200, Olivier B. a

Aucune raison en effet, et encore moins si on a une liaison full duplex.

au

Amicalement,

--
Albert.