KwxDunneKlantProtocolVoorstel

tomd, 20.apr.2001 vandaag aflevering één: De héle dunne en domme input klant. volgende keer: De iets slimmere klant, die ook kan luisteren, kan fungeren als renderer (generieke actuator, robot, motor), geconfigureerd kan worden etc. De héle dunne en domme input klant.

doel

Maak 't zo simpel mogelijk een kwx input client te schrijven en houdt die klant potentieel zó simpel is dat alles, van tini via palm tot mainframe een input kan hosten. klant moet: 1. Iets te melden hebben (locale tijd, temperatuur, Bill Gates' net worth). 2. Òf UDP òf TCP praten (luisteren hoeft dus expliciet niet) òf op een andere manier kunnen communiceren met een proxy die udp of tcp babbelt.

omschrijving

Het is hier de bedoeling dat we zonder veel moeite een stukje software kunnen maken dat mee kan doen als input in een keyworx sessie. Deze software kan op zich staan, maar natuurlijk ook een interface zijn naar externe hardware. Om het zo makkelijk mogelijk te maken en totaal taal- en platform onafhankelijk te zijn zijn de bovenstaande eisen heel summier gehouden. Hierdoor wordt het extreem simpel iets in Java of Python in elkaar te zetten wat werkt, 2 regels...

scenario

a. klant spreekt udp en kent geen server adres. b. klant spreekt udp en heeft ip adres van een server (dmv configuratie file of -scherm, hard coded, maakt niet uit).. c. klant spreekt tcp (en moet dan dus ook een server ip adres kennen). d. klant spreekt iets anders (dtmf): in dat geval zal er een proxy moeten draaien, ergens, (i.e. je belt naar een isdn kaart op een server machine waar de proxy draait) die vervolgens namens de klant één van a, b of c implementeerd. a: De klant weet niets, en kan ook niets ontvangen. Dit betekend dat alle communicatie multicast moet zijn, zowel het aanmelden als de 'data transmissie'. Als er geen server draait op het locale subnet zal de klant dus ook vrolijk voor niets blijven werken tot dat hij uitgezet wordt. Dus via het KwX-MC kanaal (waar de server dus ook standaard op moet gaan luisteren). Afhankelijk van de server software vereisten (Just?) zal de klant moeten inloggen en joinen (niet enteren, want de klant zit niet in een specifieke sessie, maar stelt zichzelf alleen beschikbaar als resource). Noodzakelijk vanuit mijn perspectief is alleen een soort meta add-resource, waardoor alle op die server lopende patchers in alle active sessies een notify krijgen, en dus weten dat er een inputmodule beschikbaar is gekomen: Hier komen evt nog allerlei andere attributes bij die ik nu over het hoofd zie. Dit geheel wordt gecodeerd in een rtp packet met payload type kUDPCodeMetaData, om de parsing makkelijker te maken (alles op dit kanaal is nl rtp). De sourceID is een beetje problematisch, dit wordt in de latere rtp data stroom gebruikt om de data uniek aan een module te koppelen, moet dus uniek zijn, en niet in de range die de GUI gebruikt (Niels?) bij het genereren van module-Id's. Ik stel een centrale registratie voor (misschien ooit via een web interface) waar alle inputmodule schrijvers een uniek 32bits id op kunnen halen... Te overwegen is een simpele crc scheck in de rtp meta data in te bouwen, zodat ontvangers boodschappen kunnen negeren die niet helemaal foutloos zijn overgekomen... Na de data een 32 bits getal volgens . Dan begint de klant gewoon de data te sturen, hij kan immers niet weten of er iemand geïnteresseerd is of niet. Standaard rtp pakketjes, payload type kUDPCodeGenericData, timestamp en sequence nummer worden genegeerd, en hoeven dus niet gezet te worden. (Zie RtPacket.h in de realizer src voor format) Iedere output heeft een 32 bits veld in het pakketje, in de volgorde waarin ze zijn aangemeldt. Als de input moe wordt, en ermee wil kappen, dan evt een De rest van het systeem moet echter ook kunnen omgaan met een minder nette 'exit'-of misschien wel niet, de 'menselijke' gebruikers kunnen dan op een gegeven moment beslissen dat input 'verySimpleMouse' wel lang genoeg stil is geweest en 'm deleten. Vanuit de Patcher gezien is een en ander relatief eenvoudig; na de notify van de server entered de patcher de modname in een menu, de gebruiker kiest dan evt de module, er gaat een naar de realizers die vervolgens weten dat de rtp generic data van sourceId vanaf nu interessant is.... Voor de Patcher is die module nu in gebruik, en kan niet nogmaals geïnstantieerd worden in die sessie (zou ook geen enkele zin hebben). De server zal nu voor dit soort input modules moeten gaan monitoren of en in welke sessies ze worden geïnstantieerd; mocht er een sessie bij zijn waar de ontvangers van de rtp (i.e. role="renderer" ) verspreid zijn over verschillende subnetten, zal de server moeten gaan 'bridgen' b: Als de client een server adres heeft hoeft er niet gemulticast te worden. Alles is eigenlijk hetzelfde als bij a, behalve dat de server gewoon als reflector functioneerd (liefst, uiteraard, alleen naar die sessies die de moduul ook daadwerkelijk hebben geïnstantieerd). Server luistert dus ook gewoon op UDP poort 5000 (naast het MC kanaal) c: Als b: De server kent, in z'n meta space, de bovenstaande XML meta tags (dit is dus op het tcp nivo van de login..) V erder zal er dan een "meta data" tag komen, die door de server meteen omgezet wordt naar udp-rtp en verder zo behandeld wordt. Principe zal wel duidelijk zijn, implementatie details af te spreken. UInt32 SimpleCRC(char *data, int length) { UInt crc = 0x65768798; while( length-- ) { crc += *data++; crc <<= 1; } return crc; } KwX-MC kanaal: IP 225.4.3.2, poort 5000 kUDPCodeMetaData 127 kUDPCodeGenericData 126