metamarty schreef op vrijdag 02 maart 2007 @ 11:00:
[...]
Het nadeel van UDP is wel dat je systeem packet loss moet kunnen accepteren. Je kan er dus niet meer vanuit gaan dat bepaalde belangrijke systeem veranderingen door komen bij iedereen. Dat legt lastige synchronisatie problemen bij de software neer. Zelf werkt ik in mijn simulatie taal met TCP, waarbij elke instantie van de interpreter systeemwijzigingen doorgeeft aan alle buren. Het vatsim netwerk was nog erger. Ik wilde daar geen storingen hebben door tussenliggende verbindingen die wegvallen zoals IRC netsplits en heb het zo gemaakt dat er redundante verbindingen mogelijk zijn. Krijg je dus ellende met interne routing en dubbel aankomende packets. Dit soort dingen zijn niet direct nodig voor simulatoren, dus enkele TCP verbindingen of UDP moeten kunnen. Je zou eventueel zelfs UDP broadcasting kunnen toepassen; dat is helemaal mooi.
Ik ben ook van plan om te broadcasten/multicasten

... Dat is ook de enige manier waarop je modules plug-and-play in een Ethernet netwerk kunt zetten. Om de seconde (of zo) stuur je een "keepalive" vanaf de server naar je broadcast adres en alle modules die op dat moment aangesloten zijn geven antwoord.
Een combinatie van TCP en UDP is overigens ook mogelijk -- RTSP gebruikt dit mechanisme geloof ik ook. Voor de "belangrijke" data gebruik je een TCP verbinding en voor de data waarbij "real-time" het belangrijkste is gebruik je UDP. Een FMC zou je bijvoorbeeld eerder op TCP aansluiten dan op UDP.
Kijk bijvoorbeeld eens op de site van
Jeroen Hoppenbrouwers' Broker. Hij heeft een universeel mechanisme ontworpen wat begonnen is om applicaties aan een oude DOS 747-400 simulator te kunnen knopen, en sindsdien zijn er al meerdere complete cockpits op gebouwd. Ik heb het geprobeerd en het geheel is ook te koppelen aan b.v. FlightGear (sinds de Broker zelf niks meer is dan een "domme" hub) maar ben niet tevreden over de prestaties van real-time data (sinds alle communicatie in plaintext verloopt).
Overigens werkt simconnect nu ook over TCP. Deze accepteert dus ook clients over het netwerk. De polling is ook overbodig geworden omdat je delta waardes aan simconnect kan aangeven die simconnect een update laten sturen zodra er een verschil in de aangegeven variabele is die groter is dan de delta.
Alleen SimConnect heeft behoorlijke performance issues. Ik heb het met Peter Dowson er al over gehad, een betere oplossing zou zijn om SimConnect voor lokale verbindingen het geheugen te laten gebruiken (in plaats van door de TCP/IP stack heen te moeten). Dit moet redelijk goed kunnen sinds het niet moeilijk is om in de event loop van FS aan te haken (ze hoeven alleen de TCP/IP eruit te slopen).
Dat klink wel een beetje als mijn msl. Een basis module gooit daar statusdata op de MSL bus en script reageren daarop en doen veranderingen op de bus.
[...]
Ja ik denk ook dat dit technisch de beste oplossing is. Helaas zijn de enige betaalbare spullen de kant-en-klare panelen die men aanbiedt en vaak via USB en proprietary software direct op FSX zitten. Dat is best jammer. Ik heb liever ook geen windows als onderlaag, vooral omdat het qua beheer niet prettig is. Het staat ook zo stom als je je cockpit op moet starten door een window te openen en op knoppen te klikken. Voor prosim werk ik zo veel mogelijk met gentoo linux.
Gelukkig spreek je hier tegen een elektro die al wel eens meer dan één printje gedevelopt heeft

... Als ik de mogelijkheden heb is het makkelijk om bijvoorbeeld in een FPGA (op een evaluatie-print) de eerste prototypes van de Ethernet-modules in elkaar te zetten. Componenten wil ik zoveel mogelijk off-the-shelf houden en controllers decentraliseren (dus bv. één controller die het Ethernet-gedeelte en UDP/TCP voor zijn rekening neemt, en één controller voor de intelligentie) en ik wil het het liefste zoveel mogelijk in DIP componenten houden zodat alles voor zelfbouw geschikt is.
Mijn scripttaal gaat XML gebaseerd worden maar ik moet nog even in de droge matter van het parsen van XML duiken. Als dat zo ongeveer klaar is heb je iets wat veel lijkt op UPnP met hier en daar wat veranderingen, bijvoorbeeld de data die een flag 'real-time' krijgt wordt als een struct (in bytes) overgezonden en niet als tekst, en de data die 'critical' gemerkt staat (zoals een failure) wordt over TCP verzonden. Needless to say wordt alle data gechecksumd net als in een echte sim
Gentoo is op simulatorgebied een erg aantrekkelijk platform sinds je elke module op de hardware specifiek kan compilen en je dus redelijk rap kan werken. Ik geloof zelfs dat er een real-time variant van Gentoo op de markt is, die erg geschikt is voor o.a. de simulatie-engine en de displays. Ik wil heel graag zelfs overstappen naar ARINC dataformats zodat ik in de toekomst misschien echte avionics in mijn cockpit kan schroeven, maar die standaarden zijn belachelijk duur en op school (ben student Luchtvaarttechnologie, heb eerst 4 jaar elektro gedaan) zijn ze niet te krijgen.