DRT technology
DRT technológia vezetői összefoglaló
A DRT technológia az internet kapcsolatok ma érvényes egyedi kliens eloszlásának
absztrakcióját centrális elrendezésű tranziens hálózatok absztrakciójával váltja fel.
A technológia bevezeti a platform független, „neuronizált” DRT alkalmazás
hálózatok fogalmát.
A technológia biztosítja a fentiek szerinti DRT alkalmazás-hálózatok (felügyelt és
szabad) teljes, szűrt, és ezek komplementer halmazainak képzését, és az így adódó
hálózatok felépítését és felügyeletét.
A technológia bevezeti és beépítetten támogatja az instant operációk, tartalom
küldés és kommunikáció fogalmát
A technológia bevezeti az alkalmazások szocializációjának fogalmát, mellyel
lehetőséget biztosít elosztott végrehajtású, és MI alapú felügyelt, vagy felügyeletlen
tanítással létrehozott tudás-reprezentációk automatikus, vagy irányított
disztribúciójára.
A technológia bevezeti az intelligens „web-asszisztens”, vagy „személyes-weblap”
fogalmát, mellyel a hálózat alkalmazásai/kliensei/alhálózatai a technológia által
biztosított rétegeken keresztül automatikus, vagy felügyelt szolgáltatásokat
biztosítanak egymásnak.
A technológia alkalmazásával enyhíthetőek a nagy technológia cégek monopol
helyzetéből fakadó jelenleg felmerülő adatvédelmi aggályok, gazdasági és szociális
irányítási előnyök.
A technológia IOT eszközökben történő alkalmazása lehetővé teszi ipari
folyamatvezérlő elvű feladatok DRT alkalmazás hálózatokkal történő támogatását.
A technológia operációs rendszer szintű alkalmazása lehetővé teszi a decentralizált
adattárolás és visszakeresés lehetőségét.
A technológia felhő alapú alkalmazása első megvalósítói számára szabványosítási és
bevezetési versenyelőnyt biztosít.
A technológia széleskörű elterjedése esetén az internet használatának ma még nem
ismert távlatai nyílhatnak meg.
Képzeljük el, milyen elképesztő dinamizmusa és hatékonysága lehet annak a jelenségnek,
hogy a számítógépeken, a telefonokon, és az IOT eszközökön futó különböző alkalmazások
képesek más számítógépeken, telefonokon, IOT eszközökön futó különböző alkalmazásokkal
rövidebb-hosszabb időre eseti vegyes hálózatokat alkotni. Majd ezek a hálózatok
lebomlanak, újak születnek, egymásba alakulnak, kiválnak, miközben a hálózat tagjai
szolgáltatásokat nyújtanak egymásnak és más hálózatoknak akár emberi kéz érintése
nélkül. Talán itt az idő, hogy megteremtsük ennek technológiai alapjait.
Prezentáció konfiguráció:
Raspberry IOT
Azur színű hálózat
Zöld hálózat
Sárga hálózat
WPF app
Szolgáltatói szerver
DRT Saját szerver
Prototípus konfiguráció:
WPF hello world App
ASP net hello world App
ASP net real App
WPF real App
WPF real App
Felhő szolgáltató
DRT saját szerver
Szolgáltatói szerver
mail: bb@gate575.hu
DRT technológia-ismertető.
Egy új technológiát szeretnénk a figyelmükbe ajánlani, mely reményeink szerint alapjaiban
változtathatja meg az internet ma használatos rendjét. Azt gondoljuk, hogy minden, amit ma tudunk
az internetről, elavultnak és idejét múltnak fog tűnni, ha ez az új technológia széles körben elterjed,
sőt ma még talán nem is sejthető új evolúciós folyamatokat fog beindítani az információs
technológia, az alkalmazások és a mindennapi élet területén...
Ez az ismertető a DRT technológia előadás/bemutató összefoglaló anyaga.
Mivel egy technológia bemutatása általában alapvetően a működés technikai részleteire terjed ki, és
így természetétől fogva száraz és talán néhol unalmas is, készítettünk egy ún. interaktív
prezentációt, amelynek segítségével a technológia alkalmazásának lehetőségeire helyezhetjük a
hangsúlyt, és a technológia technikai részleteit csak annyira érintjük, amennyire a megértéshez
feltétlenül szükséges. Az ismertető első része tehát az interaktív prezentáció használatával a
technológia alkalmazásának lehetőségeit mutatja be.
Minden technológia alkalmazhatóságának sarokköve, hogy lehetőleg tetszőleges platfomnon legyen
hozzáférhető. Jelenleg két platformon rendelkezünk működő prototípussal. A második részben
ezeknek a prototípusoknak a bemutatása következik.
Csak a didaktikai teljesség miatt néhány mindannyiunk által ismert ténnyel kezdjük, hogy érthetővé
váljék később az alapkoncepció. Ha az internet használatának egy leegyszerűsített, de jellegzetes
módját tekintjük, akkor azt mondhatjuk, hogy létezik valahol egy kliens gép (nevezzük A kliens-nek),
ami előtt ül egy operátor és egy internet cím segítségével a gépén futó böngészőben letölt egy
weblapot, és persze létezik valahol egy szerver is, ahol az illető weblap tárolva van. A böngészőben
megjelenő weblapon azután az operátor valami interakciót hajt végre, aminek következtében a
szerveren esetleg adatrögzítés zajlik, majd a weblap (vagy annak bizonyos része), többször megjárja a
szerver és a kliens gép böngészője közötti
utat. Amikor az A kliens eléri a weblapot,
természetesen lehetséges, hogy egy másik,
például B kliens is odanavigál, és szintén
letölti böngészőjébe ugyanazt a tartalmat.
Közel egyidőben akár több tucat kliens és
alkalmazás (böngésző) olvashatja ugyanazt a
lapot. Tekintsünk is egy példát.
A
szemléltetett kliensek (akik hárman vannak)
az
előbbiek
szerint
böngészőjükben
letöltötték ugyanazt
a
tartalmat. (Green
weblap) Látható, hogy mindhárom weblapon
minden funkció működik. Valamilyen termelési
jelentés demója ez, ahol a partnerek és a munkák tekinthetőek meg. A DRT technológia alap kérdése
az, hogy ilyenkor minek lehetne absztrakt értelemben tekinteni ezt a kliensekből (fizikai gépekből), és
alkalmazásokból, valamint oprátorokból álló halmazt? Lehetne ez például egy afféle erőforrás
gombóc, ahol osztott módon hasznosul a közös tartalom, vagy lehetne ez esetleg egy diszkrét
eloszlás, melyben egyedi műveletek indíthatóak? Nem elvetve mindezek lehetőségét, a DRT
technológia alapvetése az, hogy tekintsük ezt a kilensekből, alkalmazásokból, és operátorokból álló
halmazt egy Centrális Elrendezésű Tranziens Hálózatnak.
mail: bb@gate575.hu
Centrális azért, mert logikai vagy morfológiai értelemben ugyanazt a szerver tartalmat olvassák,
vagyis a tartalom/server van a középpontban. Tranziens pedig azért, mert a klienseken futó
böngészőkben az operátorok bármikor el- vagy odanavigálhatnak, és akkor a halmaz már nem olyan
elemszámú, vagyis a halmaz átmeneti. Tegyük még hozzá, hogy ehhez a hálózati tagsághoz nem
szükséges semmiféle regisztráció, tehát a technikai definició pontosabban: ez a halmaz egy
Regisztráció Nélküli Centrális Elrendezésű Tranziens Hálózat. A bázis kérdés most már az, hogy
milyen előnyökkel járna, ha létezne egy olyan technológia, amelyik képes ezt a hálózatot felépíteni?
Mielőtt erre a kérdésre megadnánk a választ, finomítsuk a modelt azzal, hogy bár az egyes kliensek
egyenrangúnak tűnnek ebben a hálózatban, de van/lehet egy kliens, akinek a státusza eltér a
többiekétől, például mert Ő a weblap tulajdonosa. Mondhatjuk, hogy ehhez a státuszhoz kiemelt
rendelkezési jogot társíthatunk, vagyis ez az alkalmazás/oprerátor/kliensgép lehet a hálózat
felügyelője. Az előbbi kérdést újra fogalmazva tehát: milyen előnyökkel jár az a helyzet, hogy ha
meglátogatok egy weblapot,
akkor részese leszek egy
hálózatnak
felügyelhetem azt? Egy ilyen
koncepció megvalósítása
és/vagy
Saját kliens a hálózatban
a
mostani sokszínű/rendezetlen
platform-viszonyok között csak
egy
egységes,
minden
platformon
implementált
technológiával oldható meg. Ez
a DRT technológia, ahol a DRT a
A hálózat többi tagja
Dendrit
munka-név
rövidítése.
Nézzünk egy működő interaktív pédát: Ha
most az egyes halmaz három böngészőjén
elindítjuk a hálózat felépítését, akkor azt látjuk, hogy az internet történetében talán először, egy
(bármilyen célú) alkalmazás látja/láthatja a köréje szerveződő tranziens hálózatot.
Egyedi név
A későbbiek megértése érdekében röviden ismertetjük a hálózat vizualizálásának elemeit. Minden
klienst egy keretbe zárt tulajdonság halmaz jellemez. A továbbiakban a kliens kifejezésbe, ha csak
külön nem említjük, mindig beleértjük a gépet, az alkamazást, és az operátor. (Ennek a technológia
kiterjesztése és a mesterséges intelligencia/gépi tanulás példa vonatkozásában majd a prototípusok
ismertetésénél lesz jelentősége) Minden kliens saját magát a hálózatban a jobb felső pozícióban
látja. Egy klienst ebben a szimbólum-halmazban a következők jellemzik: Az első ikon, a kliens
fejlécében megjelenő, az azonosítást mutató infomáció, ami egy egyedi név, bár részt vesz még az
azonosításban az internet cím, valamint a MAC szám, és egy belső tag. Amit most látunk, az egy
mail: bb@gate575.hu
hálózat, amely azonos weblap köré épült, de természetesen lehetséges más weblapok hálózatát is
létrehozni. Ezért minden hálózatnak saját azonosításra is szüksége van, amit az ikon csoport bal felső
sarkában elhelyezett lámpa szimbolizál. Mi most a zöld hálózat része vagyunk, és hogy létezik a
kapcsolat, azt a lámpa felületére rajzolt kapcsolat-ikon mutatja. Mivel a hálózat tranziens jellegű,
fontos a hálózati felépítést és tagok jelenlétét folyamatosan kijelezni. Erre szolgál a kék alapon piros
keretben elhelyezett létezés számláló, amely valójában egy dekrementálisan számláló regiszter, mely
a jelenlét megszűnésekor nulláig számlál, majd a hálózati tagság megszünik. (párhuzamosan példát
mutatunk a hálózati tagság megszűnésére)
Létezés számláló
Mivel később a technológia kiterjesztésével tetszőleges gépi és platform környezetben is felépítjük a
hálózatot, és hasznos tudni, hogy milyen hardver szolgálja ki a hálózatot, ezért kijelezzük a hardver
eszközt is. Jelenleg Desktop, Notebook, Tablet, Phone, illetve IOT eszközök megjelenítését
támogatjuk.
Desktop hardver
Az egyes hardver eszközöket a prezentációban a klienst
reprezentáló szimbólum halmaz alatti lenyíló listából
választhatjuk ki. Megemlítjük még, hogy a prezentációban a
hálózati tagsági jelenlétet, valamint a szerverrel való
hálózatépítési kommunikációt folyamatos véletlenszerűen
képzett literálok
párbeszédjével
„Beszélgetési literálok”
Szerver státusz infók
illusztráljuk. A Kliens küld
egy kérdést, és a szerver válaszol véletlenszerűen valamit, amit
a kliens felületén kijelzünk miközben a szerver a saját
működéséről ad infomációt.
A hálózati tagság, mint azt korábban jeleztük, jelenleg két
jogosultsági szinten rendezett. Lehet
egy kliens supervisor, illetve client
jogosultságú. Az alapértelmezett
Dino szem
Kiválasztott
Supervisor
Kiválasztó
tagsági jogosultság a client, amit nem is jelzünk ki. Ha egy tagság felügyeleti jogkört is elláthat, akkor
azt a kliens felületen a jobb felső sarokban egy piros S betűvel jelezzük. A későbbiekben
részletezendő szolgáltatási rétegek használatánál szükségessé válik egy-egy kliens különböző célú
kijelölése, ezt zöld alapon lévő kis pipa ikonra kattintással kezdeményezhetjük, melyre az aktuális
mail: bb@gate575.hu
kliens felülete kiválasztott állapotba kerül. Ismét feltéve azt a kérdést, hogy milyen előnyökkel járhat
egy ilyen hálózat felépítése, tagsága és felügyelete, mi arra megközelítésre jutottunk, hogy a
lehetséges előnyöket, illetve szolgáltatás alapú funkciókat csoportosítani kell. Alapvetően hat
szolgáltatási réteg kezelését támogatjuk.
Content Management Layer
Behavior Management Layer
Input Management Layer
RemoteProcess Management Layer
Interpersonal Communication Management Layer
Network Topology management Layer
Tartalom szolgáltatás
Viselkedés kezelés
Beviteli adatok kezelése
Távoli eljárások kezelése
Kommunikáció kezelése
Hálózati topológia kezelése
CML
BML
IML
RML
IPM
NML
(Fontos megemlíteni, hogy a DRT technológia használata semmilyen módon nem érinti a hosztoló
alkalmazás eredeti funkcionalitását. A DRT technológia bármikor be és kikapcsolható.
Az interaktív prezentációban a megoldás a helyi klienssel együtt max tíz tagú DRT hálózat felépítését
támogatja. A prototípusok az ún. kliens gyűrű szelektor
alkalmazásával jelenleg ezer tagú hálózat létrehozására
adnak lehetőséget. Az egyes szolgáltatási rétegek csoportos
megjelenítése, lokális kliens gyűjtő ikonja melletti „dino
Supervisor
szem”, melyre kattintva megjelenik egy grafikus menü a
szolgáltatásokkal. Ezek közül az SN feliratot hordozó
kapcsoló a single network / multi network kapcsoló, mint
szolgáltatás, azt biztosítja, hogy más hálózatokhoz is
kapcsolódni tudjon a jelenlegi zöld hálózat.
Single Network Mode
Az egyes szolgáltatási rétegek bemutatását a Network Topology Management réteggel kezdjük, mert
ezen keresztül gyorsan meg lehet érteni a rétegek működését, és később amúgy is szükség lesz rá,
amikor bevezetünk néhány DRT specifikus fogalmat. Azt már korábban is említettük, hogy az egyes
hálózatok (melyek most még azonos, de mint később, amikor bevezetjük az DRT alkalmazás-
hálózatok fogalmát látni fogjuk, hogy tetszöleges vegyes alkalmazásokból állhatnak) egyedi hálózati
azonosítóval bírnak. Jelenleg itt a prezentációban ez a zöld hálózat, amit a hálózat tagjain az egyes
lámpák szimbolizálnak. Ez a hálózat jelenleg három tagból áll. Ugyanakkor egy ettől teljesen
független weblap köré is felépült egy hálózat, a sárga
hálózat, (valamint a bemutatón esetleg az azur
hálózat), mely szintén három tagból áll. A hálózat
MultiNetWork
topológiai réteg használatára csak
a
supervisor jogosultságó operátor kaphat
engedélyt, ezért ha a zöld hálózat NML
rétegében MultiNetwork módba váltunk,
or
látjuk
az
összes
jelenleg
Kapcsolódás
Két hálózat…A sárgához még nem kapcsolódva
érvényes hálózatot a mellette lévő lenyíló vezérlőben. Itt választhatjuk ki, hogy a saját hálózatunk
mellett még melyik hálózatnak szeretnénk a tagjai lenni. Ha a sárga lámpára kapcsolunk, akkor két
állású kapcsolóként beállíthatjuk, hogy felvegyük-e a tagságot vagy nem. Ha felvesszük, akkor a zöld
hálózat megjelenítésben feltűnik a két háló uniója, amit az egyes kliensek hálózati tagság lámpáin
mail: bb@gate575.hu
láthatunk. Az új hálózat tehát hat tagból, három zöld és három sárga tagból áll. Persze a sárga
hálózat belül továbbra is csak a saját tagjait látja, mert ott nem állítottuk át a hálózati tagságot.
Zöld hálózat 3 végpont
Sárga hálózat 3 végpont
Két hálózat (zöld és a sárga) egyszerű uniója 6 végpont
mail: bb@gate575.hu
A szolgáltatási rétegek részletes ismertetése előtt az eddigi, csak webes környezetben bemutatott
technológiát kiterjesztjük más környezetekre is. Legyen egy-egy desktopos (pld WPF-es) alkalmazás
az alábbi.
WPF Desktop app (1)
WPF Desktop app (2)
Ez a WPF alkalmazás alapvető funkcionalitásait tekintve teljesen más célú, mint a korábban látott
webes felületek. Ugyanakkor az ezen a platformon is megvalósított DRT technológia támogatásának
köszönhetően képes tranziens végpontként csatlakozni a DRT hálózathoz. Ugyanazoknak az
alapvető tervezési elveknek köszönhetően itt is független az alkalmazás a DRT hálózattól. (Ezt a
korlátozást később a mesterséges intelligencia és gépi tanulás prototípus példában majd
meghaladjuk). Tegyük
fel, hogy létezik egy
zöld
hálózatunk,
Web-es alkalmazások
valamint mondjuk két
desktop-os
alkalmazásunk
két
másik (különböző)
gépen. Ha most
a
desktop-os
alkalmazásainkban is
elindítjuk a DRT hálózat
felépítés szolgáltatást,
azt tapasztaljuk, hogy a
felépülő
tranziens
Első dektop-os alkalmazás
hálózat látja a desktop-
os alkalmazásokat, ha
azok azonos hálózati azonosítást kaptak (Tartozzanak a desktop-os alkalmazások szintén a zöld
hálózathoz). Azt látjuk, hogy a korábban három tagú webes zöld hálózat most már négy tagú lett, és
az új tag az első desktop-os alkalmazás. A második destop-os alkalmazást is elindítva zöld hálózat
immár öt tagú lett. Létrejött egy Platform Független DRT Vegyes Hálózat.
mail: bb@gate575.hu
A következő platform, amin a DRT technológia képes felépíteni egy hálózatot, az az IOT eszközök
platformja. Ezen az egyszerű IOT
alkalmazáson egy három ledből álló ledsor
villogási frekvenciája állítható. Amint a
IOT eszköz alkalmazás
képeken is látható, a DRT hálózat felismeri
az eszközt, és az eszköz is felismeri a
hálózatot. Vagyis a két, illetve három
platformon egyaránt látszanak
technológia által felépített
a
DRT
vegyes
IOT eszköz Raspberry PI
alkalmazások. Itt vezetjük be a platform független
DRT alkalmazás-hálózat fogalmát, mely ebben az
értelemben azt jelenti, hogy a DRT technológia
képes tetszőleges alkalmazások között a fentiek
szerinti hálózat kialakítására, és mint később látni
fogjuk, többféle szolgáltatási típus támogatására. A
hálózatok felépítésének lehetősége pedig teret nyit
IOT eszköz Raspberry PI
az alkalmazások/kliensek/operátorok együttes erőforrás és operatív megosztás alapú
tranzakciójára. A hálózatok „neuronizáltak”, vagyis képesek egy operációs egységként kapcsolódni
más hálózatokhoz, és az így egyesített erőforrásaikkal kiszolgálni a felmerülő információs, tranzakciós
és operációs igényeket, mely elképzelés alapvetően eltér a ma jellemző, egyedi kliens eloszlás
koncepciójától.
A DRT technológia az internet kapcsolatok ma érvényes egyedi kliens eloszlásának
absztrakcióját centrális elrendezésű tranziens hálózatok absztrakciójával váltja fel.
A technológia bevezeti a platform független, „neuronizált” DRT alkalmazás
hálózatok fogalmát.
A technológia biztosítja a fentiek szerinti DRT alkalmazás-hálózatok (felügyelt és
szabad) teljes, szűrt, és ezek komplementer halmazainak képzését és az így adódó
hálózatok felépítését és felügyeletét.
mail: bb@gate575.hu
Bizonyára sokakban felmerül a kérdés, és fontos, hogy már most lássuk, milyen gyakorlati
következménye, haszna lehet ilyen hálózatok felépítésének. Vegyünk egy szemléletes, bár elsőre
kissé talán erőltetettnek tűnő példát. Tételezzük fel például, hogy a budapesti mozik weblapjai közül
mondjuk négyet, az alábbi ábrán jelölt módon többen egy időben látogatnak. Az M1 mozi weblapját
hárman töltötték le és ők a piros DRT homogén (tehát azonos alkalmazás köré felépült) hálózatot
alkotják. A végpontokat két jelölés jellemzi és ezt az ábrán a mozi azonosítójából és a kliens
azonosítójából képezzük. Pld az M1C1 jelölés azt jelenti, hogy az M1 mozi weblapját letöltő C1 kliens,
amibe beleértjük az operátort, az eszközt, és az alkalmazást (jelen esetben a weblapot). Ehhez
hasonló módon létezik még másik
három (a zöld, a kék, és a barna)
homogén DRT hálózat az alábbiak
szerint. Az egyes homogén DRT
hálózatok tagjai a saját hálózatukon
belül látják egymást, és egymással e
hálózaton
étesíthetnek,
belül
pld.
kapcsolatot
jegyeket
Zöld DRT hálózat 2
Piros DRT hálózat 3 végpont
Barna DRT hálózat 1 végpont
cserélhetnek, vagy megbeszélhetik a
film kínálatot, illetve egyéb
Kék DRT hálózat 2 végpont
szolgáltatásokat vehetnek igénybe. A
jelentősebb előny azonban akkor
jelentkezik, amikor a M4C4 kliens, aki
a barna hálózat egyetlen tagja, saját
DRT szolgáltatásában bekapcsolja a
többi hálózat láthatóságát, és egy
új hálózatot építtet fel a DRT
technológiával. Ettől kezdve
a
M4C4 kliens nem csak a M4–es
mozi alkalmazásával kerül hálózati
kapcsolatba, hanem tagja egy
kilenc
hálózatnak is, nevezetesen
három másik
végpontból
álló
új
a
mozi
alkalmazásaiból, eszközeiből és operátoraiból álló hálózatnak is.
Sőt, a hálózat-építő szolgáltatás lehetővé teszi, hogy különböző
szempontok szerint
a
halmaz „síkmetszéseivel” (később
részletezzük) újabb és újabb finomított alhálózatokat generáljunk.
Ha a kapcsolódási végpontokat ugyanis geometriai szemléltetéssel
egy sík pontjainak tekintjük, akkor a mellékelt ábrát kapjuk.
mail: bb@gate575.hu
Ezen a síkon a felső vízszintes egyenesen (tengelyen) most a mozik web alkalmazásait vettük fel, míg
függőleges irányban (tengelyen) a klienseket jelöltük. A sík maga tehát a mozik web alkalmazásai és
az éppen azokat letöltő kliensek (operátorok, eszközök) halmazát reprezentálja, amit nevezhetnénk a
„mozik web síkjának”. Ha most ezzel a síkkal párhuzamosan más, hasonlóan összerendelt
alkalmazások és kliensek síkjait vesszük fel, akkor az így kialakuló térbeli objektum egy olyan kocka,
melynek minden vízszintes síkja egy-egy, az előzőekhez hasonló „websík”. Legyen például néhány
másik entitás köré szervezhető összerendezés az éttermek, a színházak, a cukrászdák és a csoki
boltok stb.
Síkmetszet minden entitás és
azok mindegyikének egy
Csoki boltok
kliensével létrehozott alháló
Éttermek
Színházak
ozik
Síkmetszet mindből
egy entitás
mindegyik
kliensével
létrehozott alháló
Kliensek
Entitások
Ebben a kockában minden rácspont egy-egy entitás és kliens összerendelést jelent, mely kijelölhető,
mint egy hálózat része. A három síkmetszet minden külső él mentén pedig specializált, több vagy egy
entitás halmazt hoz létre. A fenti példa szerint az alkalmazásoknak igen sokféle kombinált hálózata
képezhető, ami egy adott feladat, vagy cél elérése érdekében szükségessé válik.
A következő hálózatépítési/kapcsolati szint, amikor (ahogy a prototípusoknál látni fogjuk)
meghatározott időben, meghatározott ideig a fenti hálózatok operátori kezdeményezés nélkül is
felépülhetnek, ha az alkalmazás aktív. Az így létrejött átmeneti hálózatok ezután lebomolhatnak,
újak születhetnek, egymásba alakulhatnak, szétválhatnak, miközben az eseti tagok kvázi
automatikus szolgáltatásokat nyújtanak egymásnak és más hálózatoknak. Az bizonyára nyilvánvaló,
hogy az alkalmazások ilyen elven működő hálózatai sok új, ma még talán nem is látható lehetőség
forrása lehet. Talán elég, ha arra utalnunk, hogy a hetvenes években, amikor az első dokumentumok
átmentek két egyetem között, senki sem tudta megjósolni, hogy ebből egyszer „youtube”
„facebook” „twitter” és az a kiterjedt szoftver infrastruktúra lesz, ami ma már mindennapjaink
része.
mail: bb@gate575.hu
Content Management Layer vagyis Tartalom szolgáltatás röviden CML ismertetése.
Nézzünk egy DRT hálózatot, mely három webes és egy desktop-os alkalmazás végpontból áll. A
tartalom szolgáltatási réteg célja, hogy az alkalmazások legyen képesek az operátorok, vagy az
alkalmazások számára különféle típusú tartalmakat szolgáltatni. Vagyis a DRT technológia
beépítetten teszi lehetővé különféle tartalmak megosztását. Lássunk erre egy példát. Általános
használati szabály, hogy az egyes DRT hálózati
Tartalom szolgáltatás
szolgáltatások mindig csak
a
kijelölt végpontokra
vonatkoznak, melyeket a klienseken található zöld alapú
pipával aktivizálhatunk. Jelöljünk ki, mondjuk a három
webes kliensből kettőt, illetve az egy desktopos kliensünket,
valamint, mivel ez a szolgáltatás supervisor-i jogosultságot
igényel, kattintsuk be a supervisor módot is. Ha most
tartalom szolgáltatást kérünk,
Supervisor mód
a következő felületet kapjuk. A
szöveg buborékban a fejléc
alatt található lenyíló listából, néhány előre gyártott tartalmat
választhatunk ki, melyek az Input Management szolgáltatással
szerkeszthetők. Ezek a prezentációban még olyan richtext alapú
szöveges állományok. melyek pld. egy szövegszerkesztővel is
előállíthatók. Válasszuk ki a személyes üzenet nevű tartalmat, majd ezt
követően kattintsunk a send feliratú gombra. Mivel korábban három
klienst jelöltünk ki, a küldés ezekre a kliensekre vonatkozik. Azt várjuk, hogy a korábban szerkesztett
Kijelöltek
tartalom most megjelenik a kijelölt kliensek felületén. Természetesen ez csak akkor következik be, ha
az adott kliensek éppen a hálózat tagjai, vagyis bekapcsolták a DRT technológia szolgáltatását.
Az elküldött tartalom
mail: bb@gate575.hu
A Tartalom Szolgáltatási Réteg tehát már
beépítetten biztosítja (a protónál már html
alapon és online szerkeszthetően) különféle
text alapú tartalmak (értesítések, személyes,
vagy közérdekű információk, bennfoglalt
A megjelenő tartalom szolgáltatás
képek, videók, stb.) továbbítását. Vagyis a
kliens fogalmába beleértett operátor
minden DRT technológiát támogató
alkalmazásból a saját vagy a csatlakozott
hálózatok klienseinek azonnali (INSTANT)
tartalmakat szolgáltathat, melyek mindenkihez, vagy csak a célzottan kiválasztottakhoz jut el, mely
természetesen engedélyezhető, illetve letiltható. Persze rögtön felmerülhet a kérdés, hogy ez a
szolgáltatás vajon milyen előnyökkel járhat?
A Drt technológia tartalom-szolgáltatására és általában a kommunikáció szemléltetésére most egy
valódi „életszerű” probléma megoldásának leírását adjuk meg. A „Drt ready” alkalmazása egy
vállalati információs rendszer (Denarius) mely 2005 –óta működik egy kerékpár gyártó vállalatnál. A
vállalat egy nagy múltú klasszikus kereskedelmi és gyártási tevékenységet folytató vállalkozás,
melynek telephelyén az egységes informatikai rendszer kb. 20-25 telephelyi terminálon fut. Ezen
kívül a Denarius a cég web-áruházának back-endjét is ellátja, valamint kiszolgálja a távoli
terminálokon bejelentkező kb. 10-15 az országban, és külföldön működő ügynöki hálózat tagjait is.
Vagyis a Denarius fut, a vállalati főfolyamatok szinte minden jelentős pontján, így a beszerzés, a
raktározás, az értékesítés (nagyker/kisker), pénzügy, a gyártástervezés, gyártmánytervezés, a
termelés, és az ügynökök gépein folyamatosan.
mail: bb@gate575.hu
Amikor egy alkatrész beszerzés megvalósul, a rendszer azt a raktárba történő és bizonylatokkal
dokumentált betárolással teszi felhasználhatóvá. Ezt követően egy-egy alkatrész
felhasználását/eladását a gyártás, a nagyker, a kisker, és az ügynökök, konkurens viszonyban
kezdeményezhetik, a gyártás kiszolgálásának prioritásával. Egy példaként vett alkatrész (hátsó agy)
kezdeti és további készlet állapota az alábbiak szerint alakul.
Látszik az ábrán, hogy január 8-után készlet hiány lép fel. A kereskedelmi profilú cégek alapvető
törekvése, hogy folyamatosan biztosítsák, a beszerzés és az értékesítés készlet egyensúlyát, ami
gyakran igen nehéz feladat, mert nagyon sok tényezőtől függ. Az is látszik, hogy valamikor január 12-
e körül érkezik egy úton lévő szállítmány. Nézzük, hogy alakul ki egy ilyen helyzet.
Amikor egy készlet vonatkozásában igény érkezik, a Denarius a készletet lefoglalja, és a szabad
készlet mennyiségét azonnal szinkronizálja. A példában mivel a gyártás kiszolgálása elődleges, ezért a
január elsején a Denarius-ban elkészített gyártástervezés, szükséglet-számítás és lebontás után a
rendszer automatikusan lefoglalja a szükséges mennyiséget (50 db) Ezt követően a pécsi ügynök
további 25 db-ot ad el (foglal le) 12 napos szállítási határidővel. Január 4-én kinyit a gyári mintabolt
és nagyker értékesítésben eladnak 15 db-ot. Az utolsó 10 db-ot a Békéscsabai ügynök foglalja le 9
napos szállítási határidővel. Innentől kezdve beszélhetünk készlet hiányról.
mail: bb@gate575.hu
Látszik, hogy ha most például a debreceni ügynökhöz érkezik egy 12 darabos rövid határidejű
rendelés igény, akkor el kell küldenie a vevőt, ami nem csak közvetlen gazdasági veszteséget jelent,
hanem ahogy szokták mondani, „vevői elszokással” is járhat, mert valahol máshol szerzi be a kívánt
mennyiséget és talán nem jön vissza. Mint azt korábban írtam, a vállalati főfolyamatok szinte minden
pontján a Denárius képernyője előtt ülnek az egyes szervezeti egységek operátorai, sőt a területi
vezetők is, mert a termelés és az eladás monitorozása is így zajlik. Mindannyian a Denariust
használják.
Ha a Denarius egy „DRT ready” alkalmazás, akkor az ügynökök Drt alhálózata az alábbi ábrával
jellemezhető.
Az alkalmazásban ez az alháló az alábbiak szerint tűnik fel.
Bécs
Zilah
Kassa
Siófok
Debrecen
Szeged
Pécs
Békécsaba
Esztergom
Budapest
A fent említett helyzetben a DRT technológia a legegyszerűbb szolgáltatásával a debreceni ügynök
egy minden ügynökhöz eljuttatott alábbi üzenetet küldi.
Minden ügynöknél megjelenő DRT üzenet
mail: bb@gate575.hu
Azt hogy az úton-lévő készletről információt tud adni ad a debreceni ügynök, az annak köszönhető,
hogy ebben a DRT hálózatban ott ülnek a beszerzési osztály operátorai is, akiket korábban meg
lehetett keresni a fenti módon, és tőlük ki lehetett nyerni a készlet alakulásának információit. A
fenti üzenet, tehát az ügynöki alháló minden gépén megjelenik. Kis vártatva már csak a debreceni
ügynök gépén jelenik meg egy üzenet melynek feladója a pécsi ügynök.
A fenti példa egy azonos alkalmazások köré felépült (vagyis a legegyszerűbb) hálózat és a
legegyszerűbb szolgáltatás, a tartalom szolgáltatás alkalmazásával oldja meg a keletkezett
esetenként heti/havi rendszerességű értékesítési konfliktust. Felmerülhet, hogy miért nem email-t
küld a debreceni ügynök, miért nem telefonál, vagy pld. miért nem a messengert, teams-ot, skype-
ot stb. használja. Azért mert ezekkel, sokkal lassabban és bizonytalanabbul kapna (vagy nem kapna)
választ, mint egy integrált kommunikációs felületről, ahol egyébként is mindig jelen van minden
tárgyi illetékes. Gondoljuk meg: elhagyni az éppen használt ügyviteli program felületét, megnyitni és
belépni egy másikba, ott navigálni a címzetthez, vagy címzettekhez, keresés, kiválasztás, üzenet
szerkesztés elküldés, várakozás a válaszra, majd ha megérkezett (ha megérkezik egyáltalán hiszen
lehet, hogy a másik gépnél éppen nem is a címzett ül) majd visszatérni az eredeti felületre, olyan
„overhead”, melyet a leglojálisabb és kötelességtudóbb operátorok sem vállalnak. Ezt több évtizedes
ügyviteli szoftverfejlesztési gyakorlatból mondhatom. Inkább eldobja/elutasítja a rendelést és egy
olyannal foglalkozik, aminek van fedezete. Vagyis a „Drt ready” alkalmazásban integrált
kommunikációs felület sokkal-sokkal hatékonyabb és gyorsabb kezelést tesz lehetővé, mint az ilyen
irányú külön célszoftverek, és ebben a vonatkozásában a Drt technológia kifejezetten újdonság-
tartalmú és új szemléletűnek mondható. Azt pedig még felsorolni is nehéz lenne hány féle esetben
lenne igény, ilyen komplex folyamatrendszerek esetében, a gyors és hatékony beavatkozáshoz
mail: bb@gate575.hu
kommunikáció jellegű interakcióval az adott alkalmazás által vezérelt, szabályozott
főfolyamatokban.
Ha pedig tovább gondoljuk, és például feltételezzük, hogy nem jön készlet a korábban ígért
szállításokra és a pécsi ügynök ezért nem tud felszabadítani készletet, akkor is lehet megoldás a Drt
technológiával. A cég alkalmazása a Denarius mondjuk a zöld hálózati azonosítót használja, de pld a
gyár területén van még legalább 6-8, más kerékpáralkatrész kereskedő cég. Ha az Ő irányítási
rendszereik szintén „Drt ready „ alkalmazások és mondjuk a kék, sárga, stb. hálózati azonosítót
kapják akkor a Denarius hálózata, mint korábban láttuk, kapcsolódhat más hálózatokhoz, és
beszerezheti vevőjének a szükséges készletet attól, akinek éppen inkurrenciája van, hiszen az így
létrejött vegyes hálózat alapja minden alkalmazásban a Drt technológia.
Talán nem túlzás azt állítani, hogy napjainkban a digitális eszközökkel támogatott kommunikáció
robbanásszerűen felértékelődött, és hogy ez a szükséglet, a továbbiakban is, fokozódóan és
általánosan jelen lesz mindenapjainkban. Ennek az igénynek, eddig általánosan soha meg nem
teremtett kiszolgálását adja a „DRT technológia”, amikor minden alkalmazásnak, saját és mások
DRT hálózatán belül (platform függetlenül) lehetőséget biztosít, beépítetten kommunikációt
folytatni, (minimum) az alkalmazás tárgya/célja szerinti operátori csoport tagjaival. (párbeszéd,
tartalmak, képernyőmentés, konferencia, üzenőfal, stb.)
RemoteProcess Management Layer, vagyis Távoli eljárások kezelése, röviden RML ismertetése.
A távoli eljáráshívás kezelés egy-egy feladat megoldását, a
neuronizált hálózat erőforrásait használva teszi lehetővé.
Maradjon kijelölve a korábbi három kliens, vagyis a két
webes és az egy desktop-os alkalmazás. Megkattinva a
menüt a következő felületetet nyerjük. A három képernyő
közül a bal oldali az elküldött feladat infomációit, a középső
a kapott eredményeket tartalmazza, a jobb oldali pedig a
visszaküldött üzenetek kijelzésére szolgál. A középső
Távoli eljáráshívás
képernyő valójában három, egymás fölé rendezett
eredmény felület, ahol a kapott feladatnak megfelelő
visszaadott text, kép, vagy grafika típusú megjelenítést várhatjuk. Ezek láthatósága egymástól
függetlenül csúszkákkal szabályozható, valamint a csúszkák mellett megjelenő
mail: bb@gate575.hu
jelölőnégyzetekkel az egyes kliensek
válasz eredményei tehetők
láthatóvá, vagy rejthetők el.
A
középső képernyő alatt bal oldalon
pedig van egy három combóból, és
egy nyomó gomból álló vezérlés,
melynek funkciói a következők. A
legfelső combóban látjuk azokat klienseket, melyeknek az erőforrásait használni szeretnénk. Az alatta
lévő lenyíló listából a feladatot választhatjuk ki. Itt valójában csak három task kiválasztására van
lehetőség. Válasszuk a Komplex függvény RPC item-et. Ez a feladat
azt jelenti, hogy egy többértékű függvényt (kb 7000-10000
képpont) rajzoltatunk
klienssekkel, majd
görbék pontjait
a
kijelölt
a
kiszámított
kliensenként
visszaküldjük a kérés feladójához. Ezt
követően az eredmény felületen
(mivel ez grafika), a vásznak rétegen
a kapott függvényeket megjelenítjük.
Ez
a
függvény paraméterezhető, és erre szolgál
a
harmadik combó. Itt
az
AParam,BParam,Uparam,Wparam FgnParam és StrokeParam paraméterek beállítására van mód. A
többértékű függvény kiszámítását a felosztás finomságának megfelelően pontonként végzi el a
Távoli eljáráshívás eredmény függvényei
kijelölt kliens. Állítsunk be különböző paramétereket és küldjük el a feladatot. A kapott eremények kis
idő múlva megjelennek a középső képernyőn, és láthatjuk a küldött RPC request és response
információkat is.
Látható, hogy az eltérő paraméterezésnek köszönhetően három különböző (színű) függvény-képet
kaptunk. Ezeket egyenként megnézhetjük, és a Literálok csúszka segítségével megtekinthetjük magát
a végrehajtási kódot is. Ez, mint a bevezetőben mondtuk, csak egy prezentáció, a protók már
tartalmaznak kódszerkesztőt, debuggert és fordítót is, valamint szabályozható az is, hogy a feladat
végrehajtása több szálon fusson.
mail: bb@gate575.hu
Egy másik RPC lehetőség az azonnali videó vagy kép küldése a kiválasztott kliensekhez. Ehhez most
válasszuk ki a desktop-os kliensünket, és kérjünk tőle egy távoli képet. A távoli desktop-os kliensen
kisvártatva megjelenik az alábbi felvételi ablak és elkészül egy kép, melyet a kérésnek megfelelően
elküld az RPC-t kibocsájtó klienshez. Az RPC-k használata alapvető technika a neuronizált hálózatok
működése során, ahogy azt a protók ismertetésénél több példában látni fogjuk.
Távoli kamerakép
a készítés helyén
Távoli kamerakép
a megérkezés után a kérés
kibocsájtójánál
mail: bb@gate575.hu
Interpersonal Communication Management Layer - Személyes kommunikáció kezelése
Ebben a szolgáltatásban kapott helyet a hálózat kliensei
közötti
kommunikáció,
kétirányú
mely
megvalósulhat
hagyományos, chat vagy
online
felületen.
lehetőségét
video/audio
Ennek
nem
korlátozzuk, vagyis minden
kliens egyenrangúan képes
beszélgetéseket kezdeményezni, vagy ilyen kezdeményezést fogadni. Az erre a célra szolgáló
felületen az egyes kliensek színekkel vannak megkülönböztetve a kliens nevek feltüntetése mellett. A
kliensek a beszélgetéseik tagságát csoportosíthatják, illetve a beszélgetési kezdeményezést figyelmen
kívül hagyhatják. Egy másik klienstől származó beszélgetést a kliens saját felületén feltűnő
szövegbuborék ikon szimbolizálja. Erre kattintva megnyílik a kommunikációs panel és a beszélgetés
elkezdődhet.
A beszélgetés kezdeményezhető a szolgáltatás panel ikonjára
történő kattintással,
amikor is az aktuális
hálózati
listáján meghatározható, hogy
kik vegyenek részt
kliensek
a
beszélgetésben. Mód van a
ssítésére, illetve
es
törlésére,
beszélgetés
Chat panel a beszélgetéssel
tartalmának
adott
időre
történő blokkrejtésére. Ennek
feloldása csak egy korábban
beállított kulcs megadásával
érhető el.
Sok szó esik
manapság a személyes adatok
védelméről szerte a világon,
és ezeknek a vitáknak kulcs
kérdése a beszélgetéseknek védett és védetlen közegben történő elérése illetéktelenek részéről.
Azok a megoldások, melyeket a nagy technológiai cégek kínálnak, figyelemmel arra, hogy központi
tároláson alapszanak, mindig fel fogják vetni a tárolt szöveges vagy hangalapú információk utólagos
illetéktelen hozzáférésének gyanúját. A DRT technológia alkalmazása alapvetően kizárja ennek
lehetőségét, hiszen a beszélgetések csak a klienseken, vagy a klienseket „hosztoló” azonos tulajdonú
szervereken tárolódnak, így csak ezeknek a kliens tulajdonában lévő szervereknek a fizikai elérése
(megszerzése) esetén lehetséges a bizalmas információ kinyerése. Tehát a személyes adatok a
mail: bb@gate575.hu
tulajdonosok birtokában maradnak, szemben a most jellemző gyakorlattal, amikor azt általában egy
harmadik fél (technológiai cég) birtokolja. Felmerül még a védetlen közegben történő lehallgatás-
szerű hozzáférés lehetősége, ez azonban jelentősen csökkenthető a beépített rejtési eljárások
alkalmazásával. A technológiai cégek korábban igen jelentős fejlesztési ráfordításaikat igénylő
kínálatával szemben (Skype, WhatsApp, Viber, Messenger stb.) a DRT technológia talán nagyobb
biztonságot és diszkréciót biztosíthat.
A technológia célközönsége - ahogy ezt egy erre készült üzleti modellben részletesen kifejtjük - igen
széles, hiszen használata minden létező weblap
Neuro Panel
vonatkozásában elképzelhető, akár utólag is. (Több
mint egy milliárd (csak) weblap jelenleg)
Annak szemléltetésére, hogy a technológia képes a
hálózat távoli kliensgépein,
EEG frekvenciák
illetve azok erőforrásainak
felhasználásával egészen
meglepő (ma még talán
nem
is
ismert)
szolgáltatásokra
is,
bemutatunk, egy ún. gondolatvezérlésen alapuló
szolgáltatást. Ez tulajdonképpen
a
hálózat egy pontján kezdeményezett
EEG alapú (vagyis agyhullámokkal,
emberi érintés nélküli) vezérlés,
melynek hatására
a
hálózat többi
technológia
kliense DRT
a
alkalmazásával végrehajtja a kitűzött
(„kigondolt ???”) feladatot. Legyen a
kiinduló hálózati architektúra egy DRT
vegyes
hálózat,
melyet
három
internetes és egy intranetes
kliens épít fel. Az intranetes
kliens
az
Interpersonal
Management
rétegben
aktivizálja a Neuro panelt. Ezen
egy rácsozat és egy csiga képe
látszik, valamint a panel bal
felső
agyhullámokat
progressbar csoport. A vezérlő
sarkában
egy,
az
reprezentáló
algoritmus
a
nyomó gomb
használatával
melynek
indítható,
hatására
a
progressbar csoport az egyes agyhullám tartományok szerinti frekvenciák intenzitását jelzi. A feladat
megkezdése előtt felhelyezzük az EEG érzékelésére alkalmas készüléket, mely az egyes agyhullám
frekvenciákat detektálja. Legyen a feladat a csiga mozgatása baloldalról a jobboldal felé, úgy, hogy
például a delta agyhullámok intenzitását akaratlagosan növeljük. Az agyhullámok bizonyos
kombinációja jellemző az agyban lezajló (akár) tudatos folyamatokra, így néhány általunk kitalált
mail: bb@gate575.hu
egyszerű gyakorlat után bárki számára lehetővé válik, hogy a csiga mozgását csak az agyhullámainkkal
vezéreljük. Előállítva azt az agyhullám kombinációt, melyet az erre kifejlesztett algoritmus vár, a csiga
néhány kockányit jobbra mozdul. Ha az algoritmus a várttól eltérő hullám kombinációt észlel, akkor
függőlegesen kitér.
A Dentrit technológia alkalmazásával a desktop-os gépen végrehajtott „vezérlési gondolat” a hálózat
egy, több vagy minden klienséhez is eljut. Vagyis kis gyakorlással elérhető, hogy a saját intranetes
kliens gépünkön, illetve a hálózat többi internetes kliensén is a csiga valós időben elindul balról
jobbra, ahogy azt a képe
„Gondolatvezérlés” a két különböző platformon
Ezzel a kis példával azt szerettük volna igazolni, hogy a technológia lehetővé teszi a hálózati
szolgáltatások igen széles körét, (esetleg új mime típusok létrejöttét) melynek API szerű szabványos
bővítését a fejlesztők számára biztosítani szeretnénk, megnyitva ezzel a ma még nem ismert egyéb
hasznosítások lehetőségét. Érdekes lehetőséget rejt az a jellegzetesség, amire a fejlesztés közben
találtunk rá, ti., hogy az agyhullámok kombinációi, illetve azoknak egy speciális egymás után
következő szekvenciája jellemző és személyesen egyedi bizonyos előre megtanult műveletek
esetében. Vagyis lehetséges, hogy ezek a szekvenciák egyediségük miatt alkalmasak afféle
„biometrikus azonosítóként”, vagy „biometrikus privát kulcsként” való használatra. Mivel a
fejlesztés alapvetően nem ezt az utat célozta, nem vizsgáltuk részletesebben a lehetőségeket, de
talán megérné a fáradságot.
Zöld (DRT) hálózat
Sárga (DRT) hálózat
GIROInst operációk
Végül egy napjainkban aktuális igény DRT technológiát alkalmazó lehetséges megoldásának vázlata.
A fenti példa szerint a zöld hálózat egyik kliense (eladó/vevő) csatlakozik a sárga hálózathoz, és a kék
(banki) hálózathoz majd azonnali megbízást kezdeményez a kék hálózatban az (eladó/vevő) kliens
mail: bb@gate575.hu
bankjánál. (A megkezdett tranzakció a HCT INST szabálykönyv v2.0 az Instant Hungarian Credit Transfer , magyar sajátosságokkal
kiegészített SCT Inst fizetési séma szerint zajlik). A tranzakció eredménye, hogy a zöld hálózatban kezdeményezett
azonnali átutalási kérelem a sárga hálózatban lévő kliens, mint kedvezményezett számláján instant
teljesül. Részletesebben az ábra alapján a K&H és az MKB bank között: A zöldhálózati kliens
megbízást ad a K&H bankjának egy tranzakcióra, aminek a kedvezményezettje a sárga hálózati kliens
bankja az MKB. A GIRO-on keresztül a tranzakció instant teljesül, és erről a banki DRT hálózat (kék
hálózat) szintén azonnali értesítést küld a feleknek. A fentiekhez hasonlóan képzelhetők el más
instant operációk pld: vásárlás, eladás, árverés, hitelesítés, file-csere stb.
A technológia bevezeti és beépítetten támogatja az instant operációk, tartalom-
küldés és kommunikáció fogalmát.
A DRT prototípusok ismertetése
A második részben a két platformon megvalósított prototípus bemutatására kerül sor. Elöljáróban
elmondjuk, hogy a DRT technológia minden alkalmazásba egy egyszerű kompakt vezérlés
elhelyezésével integrálható. Ennek a vezérlésnek alapállapotban igen kicsi
helyigénye van, és valójában csak egy DRT Ready feliratú címkét láthatunk. Erre
kattintva nyílik meg a teljes DRT panel, ahol kézzel (és, mint látni fogjuk később, távolról
automatikusan is) be és ki kapcsolható a működés. Lehetséges a DRT technológiai panelt ismét
elrejteni úgy, hogy közben futnak a szolgáltatások. Ilyenkor a Ready szó a címkében piros aláhúzással
látszik. A Prototípusok létrehozásánál már törekedtünk arra, hogy a vizualitás már „kivágószerszám”-
szerűen azonos legyen, valamint minden implementáció nagyjából azonos válaszidőket produkáljon.
Most két implementáció bemutatására kerül sor: az egyik egy WPF-es, a másik a hagyományos ASP
keretű megvalósítás. Tervezzük az ASPNet Core, Blazor, Webassembly, és az ASPNet MVC
implementációt is. A prototípusokban a „hagyományos” „saját tulajdonú” hálózat felügyelet mellett,
létrehoztunk a felhőben implementált hálózat felügyeletű, illetve a felhőben tárolt alkalmazást is.
Törekedtünk arra, hogy valódi alkalmazásokban mutassuk meg a használatot, de készítettünk egy
„klasszikus” induló (Hello World) alkalmazást is annak szemléltetésére, hogy a technológia tényleg
nagyon egyszerűen alkalmazható (akár utólagos „beépítéssel”). Akkor lássuk először az ASPNet-es
Hello World implementációt.
DRT panel vezérlése egy AspNet Hello World alkalmazásban
mail: bb@gate575.hu
Most indítsunk el egy példányt a WPF-es Hello world alkalmazásból is. A két hello world alkalmazás
mellé pedig indítsunk el egy-egy működő ASP és WPF-es valódi alkalmazás példát.
DRT panel vezérlése egy WPF-ld alkalmazásban
A webes működő példa legyen egy panzió webes felülete melynek kialakítása az alábbi.
DRT panel vezérlés egy valós ASPNet alkalmazásban
mail: bb@gate575.hu
A WPF-es élő alkalmazás pedig egy nyomdai vállalkozás termelés irányító rendszere.
DRT panel vezérlés egy valós WFP alkalmazásban
Az első új prototípus tulajdonság, amit bemutatunk, a hálózat elemszámának kezelése. A
prezentációban csak tíz kliens alkotta hálózat megjelenítésére volt mód, pedig nyilvánvalóan ennél
jóval nagyobb elemszámú tranziens kliens is alkothatja a hálózatot. A vezérlés, mellyel a hálózat
tagjai között navigálhatunk, az ún. Kliens Gyűrű Szelektor.
A kliens gyűrű szelektor:
A DRT panel jobb felső sarkában kapott helyet a max. 1000 kliens kiválasztását megvalósító ún. Kliens
gyűrű szelektor. Ennek használata azon alapszik, hogy a panelen
megjelenő egyszerre tíz kliens, a háromdimenziójú, egyenként 10
klienst tartalmazó gyűrűk a képernyőre merőleges „mélységi”
takarásában, szintén 10 síkban képeződnek le. A piros sokszög egy
sík 10 kliensét jelenti és a csúszkákkal az adott síkban illetve arra
merőlegesen egy-egy újsíkot jelölhetünk ki. A mellékelt jobb oldali
képen a nulladik sík nulladik kliens gyűrűje van kijelölve. A
következő képen pedig a nyolcadik sík által elérhető, azon is a
harmadik kliens gyűrű elemei
jelennek meg a DRT panel
központi felületén. Mivel 10 sík
választás lehetséges, és egy sík 10 db egyenként 10 elemű kliens-t
reprezentál, ezért a teljes hálózati kliens létszám 10*10*10,
vagyis 1000 kliens. Hogy melyik tartományban járunk, azt a
szelektor alatti tartományjelző mutatja, mely példánkban a 830-
tól a 839-is terjedő kliens tartomány. Az egyes „mélységi” kliens
síkok eltérő színnel jelennek meg a könnyebb azonosítás
kedvéért. (bemutató a kliens gyűrű szelektor használatára)
mail: bb@gate575.hu
A Viselkedési szabályok szolgáltatás ( Behavior Management Layer)
A szolgáltatások panelen az első sor második ikonjára kattintva érjük el a Viselkedési
szabályok szolgáltatást. Alapállapotban a CM felirat olvasható rajta, ami a default, ún.
Kliens módnak felel meg.
Az aktivizálás után egy beállító felületet kapunk, melyen kiválasztható a supervisor mód, az alhálózati
azonosító, valamint a kliens
eszköz nyilvános ikonja.
Minden alhálózati azonosítót
egy-egy
reprezentál. A fenti képen azt
látjuk, hogy jelenleg
eltérő
szín
a
felépített hálózat hat darab
zöld azonosítójú kliensből áll.
Itt
választhatunk
tehát
alhálózati azonosítót, pld. a
sárga lámpára kattintva. Ezt
a lehetőséget azonban csak supervisor módban
érhetjük el, amihez a nagy zöld „Client” feliratú
gombra kell kattintanunk, melynek hatására az ikon
felirat SM-re változik (supervisor mode). Ha tehát a
sárga „lámpára” kattintunk, ez azt jelenti majd, hogy
hálózati tagságunk megváltozik, és mostantól a sárga
alhálózat tagjai leszünk. Ha így
teszünk, akkor a következő hálózat
felépítési ciklusban azonnal egy
más hálózati tagság képét látjuk,
jelesen egy kéttagú sárga hálózat
tagjai leszünk, ahol a másik sárga
alhálózati tag
a zöld hálózati
körben eddig nem látszott. Azt, hogy egy kliens melyik
alhálózat tagjaként jelenik meg, a grafikus kliens profiljában
ugyanaz a kis lámpa szimbolizálja. Az egyes alhálózatok
természetesen összekapcsolhatók, ahogy a Hálózat kezelési
szolgáltatásban korábban már meg is mutattuk, például a fenti képen két hálózat unióját látjuk.
mail: bb@gate575.hu
A DRT technológia, a szocializált alkalmazások és a mesterséges intelligencia lehetőségei.
A ma már feltartóztathatatlannak tűnő mesterséges intelligencia minden bizonnyal már a közeli
jövőben állandó része lesz szinte minden alkalmazásnak, platformoktól és hardverektől függetlenül.
Szeretnénk bevezetni egy új
fogalmat, ami
technológia alkalmazásával
ma még szinte
a
DRT
beláthatatlan fejlődést és
hatékonyság növekedést
hozhat. Ez az új fogalom az
alkalmazások
szocializációja.
lehetőségek
A
olyan
sokrétűek, és a folyamat
olyan komplex is lehet,
hogy legjobb, ha egy példával próbáljuk illusztrálni a lehetőségeket. Tételezzük fel, hogy felépült egy
DRT hálózat, melynek tagjai most a fentiek.
Mint látható, a fenti képen most hat kliens szerepel, melyek webes alkalmazások, desktop-os
alkalmazások és egy Rasberry PI eszközön futó alkalmazás. Legyen minden alkalmazásnak egy-egy
mesterséges intelligenciát alkalmazó/igénylő modulja, melyet a saját tudásbázisával használ. Legyen
képes ez a modul felügyelt tanítással bővíteni korábbi
ismereteit. Ez az MI modul a hálózat minden tagjánál ezen az
azonos vizualitású felületen érhető el. A használat lényege,
hogy a képen látható virág szirmai egyenként piros, zöld, vagy
kék színűek lehetnek. A modul „tudása” pedig az, hogy egy
szabály szerint meg tudja jósolni a virág nevét a levelek színei
alapján (SDCA). A szabály az, hogy a bal felső levéltől kiindulva
jobb sodrású körüljárással a levelek aktuális színének angol
kezdő betűit adjuk meg. Például a bal oldali képen látható virág
a
szabály szerint az
RRG_Colored nevet
kapja. Alapesetben minden alkalmazás úgy indul, hogy csak
azoknak a virágoknak a nevét tudja „megjósolni”, melyeknek
legalább két szirma azonos színű. Ez az a tudás, mellyel
jelenleg minden hálózati tag rendelkezik. Ha például a
„milyen virág” gombra kattintunk akkor a modul minden
alkalmazásban a helyes „RRG_Colored” választ adja. Ha
azonban bármelyik alkalmazásban például egy három
különböző színű levélből álló virágot kreálunk a szirmok alatt
lévő színező gombokkal, és megkérdezzük az így létre jött
virág nevét, a modul most még minden alkalmazásban a „Mit
tudom én!” választ adja, mert ezt a tudást jelenleg nem birtokolja. Viszont minden modulban van
arra mód, hogy felügyelt tanítással új elemek megjósolásának képességével bővítsük az aktuális
tudást. Ehhez a felület jobb felső részén elhelyezett textboxba írt, adott levél színekhez rendelt új
elnevezést megadva, és megtanítva azt, az új kérdésre már a helyes választ fogja adni. Persze ez csak
mail: bb@gate575.hu
erre az egy kliensre és esetre lesz igaz, és csak ebben az egy alkalmazásban. A többiek számára ez a
„tudás” továbbra sem áll rendelkezésre.
A DRT technológia azonban széles lehetőségeket biztosíthat az ehhez hasonló esetekben, hogy egy
kliens által felhalmozott tudást a hálózat tetszőleges klienséhez eljuttatssunk. Sőt, az alkalmazások
szocializációja révén emberi kéz érintése / operációja nélkül az alkalmazások felvehetik egymással a
kapcsolatot, és úgy növelhetik helyi hatékonyságukat, hogy a szükséges tudást más alkalmazások
halmozták fel.
Ehhez jelöljük ki például a hálózat két webes tagját a fentiek
szerint. Most tehát arra készülünk, hogy egy desktop-os
alkalmazásban megvalósított felügyelt tanítás megnövekedett
„tudását” egy teljesen más platformon futó webes alkalmazás
számára elérhetővé, használhatóvá tegyük. A küldés gombra
kattintva a DRT technológia segítségével egy, a korábbiakban
már részletezett RPC adat modellben a desktopos kliens által
„megszerzett” új tudás a hálózat két webes tagjához érkezik,
akik ezt azonnal használni is tudják. Vagyis
a webes
alkalmazásoknak mostantól fel kell ismerniük azt a virágot,
melynek levél színsorrendje RGB
A példa kedvéért most az elküldést és a fogadást is egy-egy
üzenettel nyugtázzuk, de az a folyamat persze teljesen
automatikusan is lezajlódhat, sőt interakció is lehetséges a
kliensek között az estleges mindkét oldalon fellelhető tudás és szabály elemek intelligens
összefésülésére.
Vagyis
a DRT
lehetőség
van
technológiát
tetszőleges
platformon,
alkalmazó
eszközön
hogy
és
az
alkalmazások a mesterséges
intelligencia és gépi tanulással
szerzett
tapasztalataikat,
„szocializált”
entitásokként
megosszák egymással.
mellékelt képen azt láthatjuk,
hogy az egyik webes
A
alkalmazás úgy ismeri fel a
három színű virágot, hogy
korábban nem rendelkezett
ezzel a képességgel, és ehhez ebben az alkalmazásban semmilyen beavatkozás nem történt, vagyis
az itt működő alkalmazás egyszer csak képessé vált olyan feladatok megoldására, melyekre korábban
nem..
mail: bb@gate575.hu
A személyes weblap koncepciója
A személyes weblap (talán kellene erre egy jobb szó) koncepciója szorosan illeszkedik a DRT
technológia alapvető lehetőségeihez. Képzeljük el, hogy létezik egy olyan web-alkalmazás /weblap,
mely saját magunkat reprezentálja a weben. Ez az alkalmazás ránk jellemző, személyre szabott, és
olyan kapcsolati és funkcionális kapacitásokat tartalmaz, melyeket mi határozunk meg, illetve
egyénenként felügyelünk. A személyes weblap ugyanakkor egy web-alkalmazás, tehát a korábbiak
szerint egyedi hálózati azonosítója van, vagyis mint korábban láttuk DRT hálózatképes. Bárki, aki
ehhez a hálózathoz szeretne csatlakozni a DRT technológia segítségével, azt bármikor megteheti, ha a
csatlakozási kérelmét elfogadják.(népszerűen fogalmazva:” találkozunk a weblapomon”) Ez a web-
alkalmazás, mint láttuk képes bizonyos feladatokat, üzeneteket automatikusan fogadni, illetve
azokat, instant vagy ütemezetten, magában, vagy a DRT technológia alkalmazásával más hálózatok
kooperációjával végrehajtani, illetve továbbítani. Ma, ha valamelyik közösségi térben szeretnénk
publikálni valamit, akkor posztolunk vagy kommentelünk, és a néhány, monopol helyzetben lévő
közösségi szolgáltató, az így kikerülő tartalmakat, egy kvázi-központosított tároláson alapuló
technológiával teszi publikussá. Talán sokaknak nyilvánvaló, hogy ez struktúra és eljárásrend, néhány
komoly probléma forrása. Gondoljunk arra például, hogy milyen szélsőséges indulatú kommentelési
megnyilvánulások jelennek meg időnként, a folyamatos moderálás ellenére az egyes posztokon vagy
az azt kísérő kommentekben, ami a gerjesztett komoly emberi feszültségeket mutatja. Ennek
nyilvánvalóan az az oka, hogy mindenki ugyanazt a néhány szolgáltatót kénytelen használni, ahol
tulajdonképpen bármikor érheti őt váratlanul valamilyen irritáló tartalom, nem is beszélve az
örökösen fennálló, harmadik fél általi hozzáférés, kereskedelmi és egyéb profilalkotás gyanújáról.
Persze működik a moderálás, azzal viszont az baj, hogy időnként több feszültséget gerjeszt, mint
amennyit elsimít. Sok vita forrása, hogy milyen morális, esztétikai vagy stiláris felhatalmazás alapján
minősíti egy egyszerű alkalmazott moderátor (vagy moderátori szabályzat), mondjuk akár az amerikai
elnök kommentjét vagy másét, pozitív vagy negatív kontextusban. És nem csak az a baj, hogy
időnként szemmel láthatóan nagyobb véleményformálási potenciállal rendelkezik egy önmagát fel
nem vállaló ismeretlen entitás, mint mondjuk egy demokratikusan megválasztott képviseleti személy,
hanem az is, hogy ez újabb és újabb indulatokat generál, melyek önmagukba visszacsatolt
hurokként, állandó frusztráló személyes közérzeti feszültségeket okoznak az emberekben, melyek
egészen biztosan romboló hatásúak. Csak felvetem, hogy gondolt e már valaki arra, hogy a manapság
az egész világon végig söprő harag és indulat hullám keletkezéséért milyen felelősség terheli a
közösségi média üzemeltetőit. Szeretném leszögezni, hogy nézetem szerint nem a feltételezett
tudatos rosszindulat, vagy szándékosság okán, hanem egyszerűen a monopolizált struktúra
hibájából. A közösségi média néhány hegemón csomópontú szerkezete kumulálja a feszültségeket,
és állandó irritáló hatása miatt, előbb utóbb ilyen vagy olyan formában akár, társadalmi természetű
és méretű anomáliákat generálhat. A megoldás az lehet, hogy diverzifikálni/szétosztani kell a
közösségi terek feszültségi potenciálját, és erre DRT technológia korrekt megoldást kínál. A DRT
technológiával és a személyes-weblap koncepciójával, a meglévő koncentrált terek mellett
mindenkinek lehet „saját facebook-ja” vagy „saját twitter-e” „saját instája” Az ilyen közösségi tér
saját „moderációját” a „széles többiek” irritálása nélkül elvégezheti, illetve csak olyan DRT
hálózatokkal alakít közösségi teret, akik számára valóban relevánsak, és ezzel nem mellékesen
visszaadja a személyes adatok függetlenségét és normál életben megszokott, „kapcsolat kezelés”
szabadságát. Hiszen ha egy ismerősökből álló csoport tagjai személyes kapcsolatba kerülnek
egymással, akkor sem felügyeli/moderálja őket senki és ez mindenki számára egy megszokott és
elvárt körülmény. A koncentrált közösségi terekben pedig maradhat a moderálás mostani formája és
a talán kevesebb feszültség. Persze mindannyian tudjuk és nyilvánvaló, hogy a közösségi terek
mail: bb@gate575.hu
nyereségorientált gazdasági vállalkozások is, és ez a tény bizonyára szintén meghatározó szempont
ezért bizonyos irányban nehezen
reformálhatóak. A DRT technológia és
a
személyes-weblap
viszont
lehetőséget teremt, hogy mindenki aki
ezt szeretné, akár teljesen saját
felügyeletű közösségi teret hozzon
létre.
A személyes-weblap másik előnye,
hogy a DRT technológia támogatása
miatt olyan funkcionalitásokat és
információkat is kínál, melyeket más
hálózatok birtokában vannak és ezek,
mint beépített hálózati szolgáltatás az
alkalmazások között elérhetők.
Alkalmazás szintű DRT üzenő-fal
saját moderálású poszt és komment
lehetőség..
Erre példaként álljon itt egy elsőre
talán futurisztikusnak, sőt megmosolyogtatónak tűnő, de a DRT technológia széleskörű
alkalmazásával a fentiek szerint, valójában szinte karnyújtásnyira lévő lehetőség. Képzeljük el, hogy
a vállalkozásoknak, szolgáltatóknak és mindenkinek lehet/van ún. intelligens személyes weblapja. Ez
mint fent kifejtettük egy olyan web-alkalmazás, mely az adott személyt, üzleti vállalkozást, operációs
vagy kereső központot, stb. reprezentálja a „kíbertérben”. Egyfajta digitális asszisztensnek tekintsük,
aki mindig szolgálatra kész, és akinek mi magunk személyesen, vagy más szocializált digitális
entitások, operátorok különböző feladatokat, üzeneteket adhatnak. A kapcsolat alapja pedig
mindig a DRT technológia. Lehetséges például, hogy reggel, amikor felkelünk, utasítjuk a személyi
weblapunkat, hogy keressen, nagyjából 15 km-es körzetben egy olyan szervizt, ahol az autónkat
levizsgáztatják, mert nemsokára lejár az érvényessége. A vizsga ne legyen 30eFt-nál drágább,
valamint szerezzen nekünk két jegyet egy általunk kiválasztott filmre bárhol a városban, csak az a
kérésünk, hogy utána foglaljon le egy asztalt két személyre valahol, de az étterem ne legyen
távolabb a mozitól mondjuk 10 km-nél. A személyi weblapunk felkeres más, a DRT technológia által
támogatott szocializált alkalmazásokat, kérdéseket tesz fel nekik, elemzi a válaszaikat, majd
valamikor délelőtt értesít minket, hogy a vizsga el van intézve, az ára 25 eFt, a dátum pedig a jövő hét
péntek nyolc óra. Azután felkeresi a mozik digitális asszisztenseit, akikből kiválaszt egyet, akinél
megvásárolja a jegyeinket, miközben párhuzamosan elemzi a környékbeli éttermek elérhetőségeit,
végül délután tájékoztat minket arról, hogy ezt is sikerült elintéznie, de sajnos a mozi-étterem
távolság nem tíz, hanem 11.4 km, itt az útvonal terv és a várható átlagos menetidő. Ezekhez az utóbbi
adatokhoz pedig csatlakozott valamelyik útvonaltervező alkalmazás hálózatához, és tőlük nyerte ki a
közlekedési viszonyok adatait. A fenti folyamatoknak pedig az igazi újdonsága az, hogy a szocializált
alkalmazás a számára kiadott feladatokhoz szükséges hálózati kapcsolatokat a feladat kiadásának
pillanatában nem kell ismernie. Viszont a különböző tranziens DRT hálózatokhoz való
kapcsolódásának képességével (erre láttunk példát korábban, amikor egy alkalmazás több DRT
alkalmazás hálózathoz tartozhatott egy időben) és a mesterséges intelligencia alkalmazásával
„felderítheti”, vagy afféle kereső hálózatok segítségével megtalálhatja a szükséges hálózatokat, és
így sikerrel megoldhatja a kapott feladatokat.
mail: bb@gate575.hu
Tartalom szolgáltatás (CML)
Ennek a szolgáltatásnak a
használata lehetővé teszi,
hogy
tetszőleges
szerkesztett tartalmakat küldjünk a
hálózat tagjainak, melynek alapja
valamilyen html file. Vagyis egy szerkesztett html file (ami tartalmazhat a szövegen kívül egyéb típusú
tartalmakat is) küldhető el. Ennek a szolgáltatásnak az aktiválásához a bekezdés elején látható ikonra
kell kattintani, melynek hatására feljön a Tartalom szolgáltatási szerkesztési és küldési felület. Vagyis
most három alkalmazást látunk, melyek lehetnek webes, desktopos, IOT, stb. különböző platformon
futó és eltérő célú alkalmazások. A termelésirányítás alkalmazásban a beolvasás gombra kattintva
beolvasunk egy előre megszerkesztett tartalmat, mely legyen egy esküvői meghívó.
A menüsor
továbbítása
ikonjára, vagy a fővezérlő Elküldés ikonjára kattintva megtörténik a tartalom
korábban kijelölt kliensekhez. Ennek eredményeként Termelésirányítás
a
a
alkalmazásban, és a teszt alkalmazásban is megjelenik a küldött tartalom.
Természetesen a tartalmat hordozó ablak eltűntethető a jobb felső sarokban lévő ikonnal. Mód van a
tartalmak közvetlen szerkesztésére, de külső html szerkesztő (Pld. Word) használatával készített
állomány is beemelhető. A megszerkesztett tartalom, a megjelenési pozíció, valamint a megjelenítési
méret adatokkal egy saját formátumban, „.drtcm” kiterjesztéssel lementhető.
mail: bb@gate575.hu
Távoli osztott feladat végrehajtási szolgáltatás ( RPCML)
Ennek a szolgáltatásnak a használata a második ikonsor első ikonjával aktivizálható. Hatására
megnyílik egy RPC (Távoli eljárás hívás) kódszerkesztő felület az alábbiak szerint. A most
következő demó szinte semmiféle gyakorlati előnnyel nem bír. Nem azért készítettük, mert
úgy gondoltuk, hogy ez valós igény, hanem mert kiválóan alkalmas az RPC-k egyik általános és valódi
előnyének igazolására. Ennek magyarázatára a teszt végén a végrehajtási idők elemzése részben térünk
ki.
Jelenleg alapvetően két fajta RPC típus létezik. Az egyik az ún. Standard beépített RPC, melynek kódja
védett és nem módosítható, de paraméterezhető, valamint a felhasználó által szabadon (pld. c#
mail: bb@gate575.hu
nyelven) „kódszerkeszthető”, és paraméterezhető RPC. Az RPC kódszerkesztő és aktivátor az a felület,
ahol kiválaszthatjuk az egyes klienseknek elküldendő RPC feladatokat, valamint azokat paraméterekkel
láthatjuk el, illetve a felhasználói RPC-k esetében helyi kódfordítást vagy tesztfuttatást indíthatunk. A
szerkesztett RPC-ket lementhetjük, törölhetjük, és/vagy módosíthatjuk. A részletes ismertetés előtt
küldjünk például az összekapcsolt hét tagú hálózatunknak egy olyan feladatot (mint a korábban használt
interaktív prezentációnál), melynek lényege, hogy a kiválasztott kliensek egy-egy többértékű függvény
függőváltozóit kiszámítják, és a saját erőforrásaiknak a felhasználásával vizualizálják, majd az eredményt
visszaküldik a kérés tulajdonosához. Az egyes futások eredménye egy transzparens felületen egyszerre,
vagy külön-külön megjeleníthető. Az egyes kliensek a kapott feladatról futási, illetve hibaüzenet naplót
írnak, amit szintén visszaküldenek az RPC kérés tulajdonosának, amit az megjelenít(het). A fogadó
oldalon a visszaadott eredmények mime típusának megfelelő automatikus kezelést biztosít a
technológia.
A jelenleg támogatott mime típusok az alábbiak:
TEXT,HTML,GIF,JPEG,PNG,MP3,CANVAS,WAV,MPEG,DBF,DRTCOMPERROR,DRTRUNERROR
A
kódszerkesztő felső harmadában három lenyíló lista található, melyek rendre:
Az elsővel a tárolt RPC-et választhatjuk ki, ahol az Std_kezdetű RPC-k írásvédettek, mint azt a mellettük
lévő jelölőnégyzet is mutatja. (Std_Canvas_RPC) Az utolsó RPC egy ún. felhasználói RPC, melynek kódját,
paraméterezését, valamint célját, illetve visszaadott eredményét a kód szerkesztője szabadon
szerkesztheti, fordíthatja, illetve teszt futtathatja. (User_ToString_RPC).
A második gyűjtemény a kiválasztott RPC paraméter listája, melynek szerkesztését az RPC használója
szabadon beállíthatja.
A harmadik gyűjtemény a kód fordításához szükséges assembly-k felsorolását tartalmazza, szerkesztése
csak a felhasználói RPC esetén megengedett.
A kódszerkesztő ablak alatt egy ikon sor található az egyes szerkesztési, indítási, fordítási és
karbantartási műveletekre.
Az egyes ikonok jelentése
A fordítást elindító ikon, mely a kódszerkesztőben lévő forrásállomány fordítását végzi. A
fordítás eredménye egy információs felületen jelenik meg az alábbiak szerint
mail: bb@gate575.hu
.
A fordítási és szerkesztési oldalon futtatja az RPC-t tesztelési és hibakeresési célból, úgy, mintha
az egy távoli kliensen futna.
A fordítási eredmény ablakot kapcsolja ki és be
A kiválasztott RPC-t elküldi a kijelölt távoli kliensekhez a beállított paraméterezéssel.
A távoli klienseken lefuttatott RPC-k eredmény adatainak megjelenítését valósítja meg.
Ezen a felületen az egyes „mime” típusok, és az
egyes távoli kliensek szerint kapott eredmény
adatok jeleníthetőek meg , a korábban már
ismertetettek szerint. Az alsó vezérlő panelen
látható egy jelölőnégyzet sor, mely az egyes
kliensek
megjelenítését,
szabályozza.
eredményadatainak
egységes
láthatóságát
kliens
illetve
Minden
eredményvezérlőjében
a jelölőnégyzet sor
fölötti csúszka sorral szabályozható a text, html,
image, dbf,video, log, és error kimenetek
láthatósága. Az egyes kliensek eredmény adatainak gyűjteményeit úgy kell elképzelni, mintha egymás
fölött rétegesen helyezkednének el. Most az Std_Canvas_RPC küldését valósítjuk meg, tehát canvas
fogadására
állítjuk
(kép)
a
be
megjelenést, és hét
kliensre számítunk.
Először kijelöljük a hét
távoli klienst, ami
igazából csak hat távoli
kliens, hiszen egyszer a
saját alkalmazásunkkal
is elvégeztetjük
számítást.
a
Most pedig az előbb ismertetett szerkesztő és aktivátor felületen elküldjük az RPC-ket a távoli
kliensekhez. Az eredmény kis idő elteltével a következő az egyes kliensek szerint:
mail: bb@gate575.hu
Mindezek együttesen a fenti grafikai eredményt adják, ha az egyes eredményadatok panelen a text
és az audio-video felületek láthatóságát letiltjuk.
Mindemellett
a
távoli kliensek naplóbejegyzéseit is
megtekinthetjük, ha a LogResult megjelenítési réteget
láthatóvá tesszük. A kód úgy van megírva, hogy az egyes
futások az rndFlg alapján vagy a kapott paraméterek szerint
zajlanak le, vagy azokat véletlenszerűen állítják be, ezért
minden futás más és más távoli kliens oldali eredménnyel
jár.
cnvResult.Children.Clear();
bool rndFlg = Convert.ToBoolean(args[0]);
Random rnd = new Random(DateTime.Now.Millisecond);
double AParam = Convert.ToDouble(args[1]);
double BParam = Convert.ToDouble(args[2]);
double UParam = Convert.ToDouble(args[3]);
double WParam = Convert.ToDouble(args[4]);
double IParam = Convert.ToDouble(args[5]);
ColorParam = Convert.ToInt32(args[6]);
cnvResult.Width = 700;
cnvResult.Height = 450;
if (rndFlg)
{
AParam = (double)rnd.Next(-50, 50);
BParam = (double)rnd.Next(-50, 50);
UParam = (double)rnd.Next(-10, 10);
WParam = (double)rnd.Next(-10, 10);
ColorParam = (int)rnd.Next(0, 9);
IParam = 250.0;
}
Mint azt korábban is említettük, az
egyes hálózati funkciók nemcsak a
kliensek között zajlanak, hanem implicit
módon az alkalmazások között is, mely
számtalan új lehetőséget vet fel. Az
előzőekben minden kliens egy-egy
többértékű függvény kiszámítását és
vizualizálását valósította meg saját
erőforrásainak felhasználásával, és az
eredményt, vagyis a hét kliens által
kiszámolt hét képet egymás fölé
helyezett rétegeken jelenítettük meg. A
technológia beépítetten támogatja
osztható feladatok olyan végrehajtását,
melyben a kliensek programozottan,
vagy automatikusan, skálázva, több
szálon hajtják végre a kapott feladatot.
A beépített actor alapú végrehajtás
alkalmazásával az előbbi példához
hasonlóan utasíthatjuk a klienseket,
hogy saját erőforrásaik alkalmazásával
tetszőleges számú többértékű függvényt vizualizáljanak.
mail: bb@gate575.hu
Legyen a felépült hálózat a fenti, ahol mindössze két kliens alkotja a DRT hálózatot.
Kijelölve végrehajtásra mindkét klienst,
és távoli végrehajtást kiválasztva,
megjelenik a korábbi RPC kódszerkesztő
és aktivátor. listából az
Std_ActorCanvas_RPC-t kiválasztva
a
A
elküldhetjük a kilensek számára azt a
feladatot, hogy mindegyikük egyenként,
a példa szerinti hét függvényt számolja ki,
és rajzolja meg. Az elküldés után a
kliensek
az
egyes
vizualizálási
feladatokat
külön-külön
szálakon,
aszinkron módon valósítják meg, és az
egyes eredményeket egyetlen canvason
jelenítik meg, majd visszaküldik a kérés
kibocsájtójához. Vagyis most egy kliens
számol ki annyi képpontot, mint az előző
példában a hét kliens együtt, tehát 70000 képpont kiszámítása történik kliensenként, vagyis
összesen 140000.
mail: bb@gate575.hu
Az elsőként végző kliens által generált canvas 70000 képpontot tartalmaz, és a fenti ábrán látszik.
Ezek a képpontok hét, az első példában ismertetett többértékű függvény egy canvason történő
ábrázolása. A másodikként végző kliens az alábbi képpel tért vissza.
mail: bb@gate575.hu
Látható, hogy a képek sokkal összetettebbek, mint az előző példa egyenkénti eredményei, hiszen
éppen hétszer több pontot tartalmaznak.
A következő ábrán pedig az egyik kliens futási log-ja látható, az egyes aktorok szál-azonosítóinak
feltüntetésével.
Az
RPC
képesség
a
DRT (hálózatban) technológiában lehetővé teszi különféle eszközök, platformok között az osztott
feladat-végrehajtást.
A végrehajtási idők elemzése:
A napló állományból az is látszik, hogy egy-egy szál által végzett munka összes ideje kb. 333
másodpercet vett volna igénybe, ha a kliens sorosan hajtotta volna végre a számítást. Így, hogy
külön szálakon, aszinkron módon történt a végrehajtás, mindössze 57 másodpercbe telt. A
hatékonyság növekedés tehát jelentős. (582%).
Felhasználói RPC készítése és futtatása
A felhasználói RPC-k kódja, paramétereinek száma, és azok felhasználása szabadon szerkeszthető a
küldési oldalon. Példaként álljon itt egy, a klienseken egy MessageBox-ot megjelenítő RPC, melynek
kódja az alábbi.
using System;
using System.Windows;
using DRT_CommonCore.RPCClasses.RPCBases;
namespace DRTCodeTemplate
{
public class RPCTest : RPC_Request
{
public override RPC_Response RPC_Executer(string[] args)
{
string p = args[0];
// Paraméter illesztés
MessageBox.Show("Hello DRT World! param:" + p,"User_Message_RPC process",
RPC_Response retval = new RPC_Response(); // Visszaadott objektum
retval.RPC_RequestName = "User_ToString_RPC"; // Az rpc kérés neve
MessageBoxButton.OK);
retval.RPC_ResponseLog += "\nClientName:" + ClientName + "\n
" +
"request : User_ToString_RPC" +" \n
"
+
"executer running. at:" + DateTime.Now;
retval.RPC_ResponseData = "User_ToString_RPC ok! [" + p + "] Végrehajtva: " + DateTime.Now; //
Visszaadott string
retval.RPC_ResponseMimeType = DRT_CommonCore.Helper.DRTMIMES.TEXT;
return retval;
}
mail: bb@gate575.hu
}
}
Mint látható, egy RPC_Request osztályból származik minden felhasználói RPC. Ezen osztály
RPC_Executer(string[] args) nevű metódusának a felülírásával operálva adhatunk saját
kódtartalmat a küldendő RPC-nek. Ebben a példában csak egy paramétert használunk, és
megjelenítünk egy MessagBox-ot, melyben a „Hello DRT world” literált, valamint a kapott
paramétert írjuk ki. Ha lementettük a felhasználói RPC kódját, még a küldő oldalon fordíthatjuk és
tesztelhetjük.
mail: bb@gate575.hu
A programban elvárunk egy paramétert, melynek felvételét a középső gyűjteménynek a (+) ikonjára
kattintva tehetjük meg.
Látható, hogy a paraméter a „Küldve: 2016.05.26. 10:23:00” literál. Ezek után a „fogaskerék” ikonnal
elindíthatjuk a szerkesztési oldalon a tesztfuttatást. Ennek a hatására a szerkesztési oldalon lefut a
fordítás és rákerül a vezérlés a felhasználói RPC kódjára, mintha azt egy távoli kliens kezdeményezte
volna.
Az alkalmazásoknak nem kell kötelezően azonos alkalmazásoknak lenniük, ami a technológia igen
széles hasznosíthatóságát jelenti.
mail: bb@gate575.hu
Mostantól a felhasználói RPC futtatható a DRT technológiát alkalmazó klienseken is, ahogy azt a
hosztoló és a teszt alkalmazásunk képernyője is mutatja, mivel magunknak is elküldtük a felhasználói
RPC-t.
Különösen nagy távlatokat nyit a technológia IOT eszközökben történő alkalmazása. A fentiek szerinti
szocializált alkalmazásokként futó IOT rendszerek olyan, ”emberi kéz érintése nélküli” intelligens
hálózati tranzakciók lehetőségét teremtik meg, mely az ipari folyamat-vezérlésben ma még
elképzelhetetlenek. Dolgozunk egy ilyen bemutatón is.
A Dendrit operációs rendszer.
Továbbgondolva azt az alapelvet, hogy szolgáltatás alapú, tranziens alkalmazás-hálózatok
épülhessenek fel, és azok végpontjai között tetszőleges operációkat valósítsunk meg, illetve, hogy
ezek a hálózati tagságok szabadon
változtathatóak legyenek, felvetődik
egy olyan operációs rendszer
lehetősége,
mely
beépítetten
tartalmazza
a DRT hálózatok
kezelésének/kialakításának
lehetőségét. Régóta napirenden lévő
és logikus kérdés, hogy vajon
meddig és milyen hatékonysággal
képes
követni
a
keletkező
információk mennyiségét a tárolási
infrastruktúra. A technológiai cégek
ma elképesztő mennyiségű szervert
üzemeltetnek és helyeznek üzembe
nap, mint nap, hogy követni tudják az igényeket. Egy ideig biztos még lehet ezt a stratégiát követni,
de a végtelenségig bizonyára nem. Talán egy másik, a hálózattal automatikusan együtt bővülő
stratégiával azonban lehetséges lenne ennek az ellenmondásnak a feloldása. Ha például minden
újonnan létesült hálózati végpont beépítetten tartalmazná a bővülő tárolókapacitás lehetőségét,
akkor a hálózat mintegy maga skálázná tárolókapacitását a növekedő igényekre. Egy technológiai
megoldás lehet például, ha a szolgáltatók által kihelyezett eszközök, illetve a felhasználó saját DRT
szervere tartalmaznának tárolókapacitást, melyet egy erre alkalmas technológia képes lenne elérni
és oda adatokat menteni, illetve azokat onnan kinyerni. Vagyis a nagy, központosított adattárolást
felváltaná, illetve sokkal inkább kiegészítené a hálózati szolgáltatási végpontokra telepített, osztott
használatú infrastruktúra, persze a kötelező adatbiztonság biztosítása mellett. Ennek egyik lehetséges
mail: bb@gate575.hu
megoldása egy olyan operációs rendszer, mely tranziens hálózatok felépítését beépítetten
támogatná a korábban kifejtettek szerint. Erre egy olyan szerény prezentációt fejlesztettünk ki,
melynek alapja egy bankkártya méretű számítógép, a ma oly divatos Raspberry Pi. Mivel a WinIOT
lehetőséget biztosít arra, hogy a saját alkalmazásunk „uralja” a hardvert, célszerűen ezen a
platformon készítettünk egy kis „operációs rendszert” elképzeléseink bemutatására. Egy-egy ilyen kis
számítógép alkalmas lenne operációs rendszerével, hogy esetenkénti tranziens hálózati végpontként
kiszolgálja a hozzá érkező kéréseket.
A DRT technológia és a külvilág.
Az előzőekben említett szolgáltatások a hálózat tagja között
kiterjeszthetőek az egyes hálózati végpontok közvetlen
környezetére is minden olyan szabályozási, vagy vezérlési
feladat megoldására, mely az adott kliens gép hatókörében van.
Még egyszerűbb, ha az előző bekezdés értelmében olyan speciális hardvert alkalmazunk, melyet a
DRT technológia támogat. A következőkben egy Raspberry Pi 3 alkalmazást mutatunk be, mellyel a
tranziens hálózat tagjaként vezérlési feladatokat látunk el, nevezetesen villogtatunk három ledet egy
próba panelen, miközben az eszköz egy DRT hálózat tagja is.
A fenti képeken látszik, hogy az IOT eszközön futó kis operációs rendszer látja a DRT hálózat
alkalmazásait és egyenrangúan kezeli azok szolgáltatásait, valamint képes a hálózat számára
szolgáltatásokat nyújtani, pld. változtatja az eszköz által vezérelt ledek villogási frekvenciáját.
A DTR technológia működésének finom hangolása:
A hangolható funkciók ezek alapján a következőek:
1. Beállítható, hogy az egyes kliensek élettartam mutató számítása hol történjen. Lehetőség van
a szerver, illetve a kliens oldali életciklus kezelés beállítására.
2. Lehetőség van az életciklus timerének kézi beállítására 1000 ms-tól 100000 ms-ig.
3. Beállíthatjuk, hogy a fent említett „watch dog” intervallum beállítása kézzel történjék, vagy a
terhelés függvényében automatikusan.
4. Az egyes kliens „ping-ek” tárolási stratégiája választható egy szerveren lévő adatbázisban,
illetve egy, a szerver memóriájában lévő memória cache-en történő tárolásra.
5. Beállítható a kliens saját „ping” intervalluma, vagyis az az idő, amelyben egy létező kliens
ciklikusan regisztrálja magát a hálózaton.
6. Lehetőség van az egyes klienseken alkalmazott DRT
komponens meghatározott időben történő távoli indítására,
illetve leállítására. Ez azt jelenti, hogy a bejegyzett kliens egy
adott időpontban automatikusan elindítja
a hálózat
felépítést, és a hálózat rendelkezésére áll, illetve a
megfelelő időpontban lekapcsolja magát a hálózatról.
A fenti beállítások csak Supervisor módban érhetők el, és a „watch
dog”–ot reprezentáló „Tobi” nevű kutya ikonra kattintva jelennek
meg. Amikor a hálózat felépítését elrendeljük, a „watch dog”
folyamatos működését a Tobi kutya animációja jelzi. Az egyes
beállítási funkciók a következő képen láthatók.
A technológia bevezeti az alkalmazások szocializációjának fogalmát, mellyel
lehetőséget biztosít elosztott végrehajtású, és MI alapú felügyelt, vagy
felügyeletlen tanítással létrehozott tudás reprezentációk automatikus, vagy
irányított disztribúciójára.
A technológia bevezeti az intelligens „web-asszisztens”, vagy „személyes-
weblap” fogalmát, mellyel a hálózat alkalmazásai/kliensei/alhálózatai a
technológia által biztosított rétegeken keresztül automatikus, vagy felügyelt
szolgáltatásokat biztosítanak egymásnak.
A technológia alkalmazásával enyhíthetőek a nagy technológia cégek monopol
helyzetéből fakadó jelenleg felmerülő adatvédelmi aggályok, gazdasági és
szociális irányítási előnyök.
Technológia IOT eszközökben történő alkalmazása lehetővé teszi ipari
folyamatvezérlő elvű feladatok alkalmazás hálózatokkal történő támogatását.
mail: bb@gate575.hu
Kliens ciklikus regisztráció
Tobi a WatchDog működés
és a hangolása -> ki/be
WatchDog frissítés beállítása
WatchDog intervall kézi
vagy automatikus kezelése
Életciklus kezelés (server/client)
Tárolási stratégia
Adatbázis/Memória cache
DRT kliens ébresztés
regisztráció
mail: bb@gate575.hu
A DRT technológia a felhőben
Megírtuk a DRT technológia felhő alapú támogatását is, ahol a hálózat felépítését egy (esetleg)
automatikusan skálázódó felhő-alkalmazás valósítja meg, Mutassunk erre is egy példát:
mail: bb@gate575.hu
DRT technológia, mint az internet/informatika evolúciójának új fejezete.
Ahogy a fenti címben írtuk, gondoljunk erre a technológiára úgy, mint az internet/informatika egy
következő evolúciós állomására. Kezdetben voltak az egymástól független számítógépek, melyek
operációs rendszerei egyszerre egy program futását támogatták. Őket felváltották az időosztásos
elvek alapján működő operációs rendszerek, melyek egyszerre több program futtatásával növelték az
erőforrások kihasználhatóságát. Ezt követte a lokális hálózatok kora, melyben az egyes számítógépek
olyan helyi hálózatokat alkottak, melyek lehetővé tették, hogy az hálózat tagjai egymás erőforrásait
megosszák és egymás között szinte megszámlálhatatlan módon cseréljenek adatot. Újabb állomást
jelentett az internet megjelenése, mely lehetővé tette, hogy a lokális hálózatok kliensei egy hatalmas
világméretű hálózat tagjaiként operáljanak. A Dendrit technológia, mint a következő evolúciós
állomás pedig annak a lehetőségét teremti meg, hogy az egyes intranetes, desktop-os és webes, IOT-
s kliensek (neuronizált) tranziens alkalmazás hálózatok speciálisan összetartozó, platform független,
variábilis logikai egységeiben legyenek képesek az eddigieknél ismét egy szinttel magasabb
organizációra, mintegy új absztrakciós rétegként az eddigiek felett. Különösen aktuálissá teszi az
előbbiekben ismertetett kapacitásokat a rohamosan fejlődő, mesterséges intelligencia alapú
alkalmazások térnyerése. Egy-egy feladat megoldása a DRT technológia felhasználásával, az eseti
hálózati erőforrások felderítésének és használatának segítségével automatikusan skálázhatóan,
„emberi beavatkozás” nélkül valósulhat meg. Ilyenkor az alkalmazás „megkeresheti” a megoldáshoz
szükséges „DRT erőforrás hálózatokat” úgy, hogy a felhasználó ezt nem is érzékeli, hanem csak az
eredményt kapja készen rövid válaszidővel.
Képzeljük el milyen elképesztő dinamizmusa és hatékonysága lehet annak a jelenségnek, hogy a
számítógépeken, a telefonokon, és az IOT eszközökön futó különböző alkalmazások képesek más
számítógépeken, telefonokon, IOT eszközökön futó különböző alkalmazásokkal rövidebb hosszabb
időre eseti vegyes hálózatokat alkotni. Majd ezek a hálózatok lebomlanak, újak születnek,
egymásba alakulnak, kiválnak, miközben a hálózat tagjai szolgáltatásokat nyújtanak egymásnak, és
más hálózatoknak akár emberi kéz érintése nélkül. Talán itt az idő, hogy megteremtsük ennek
technológiai alapjait.
A technológia felhő alapú alkalmazása első megvalósítói számára szabványosítási és
bevezetési verseny előnyt biztosít.
A technológia széleskörű elterjedése esetén az internet használatának ma még nem
ismert távlatai nyílhatnak meg.
mail: bb@gate575.hu
mail: bb@gate575.hu