Jump to content

TCP/IP és UDP protokollok, vezetékmentes hálózaton


jiu88
 Share

Recommended Posts

jiu88

Sziasztok!

 

Hardver és szoftver kérdésem van.

Adott egy laptop és egy számítógép. A laptop egy PCMCIA WLAN kártyával van felszerelve, és ezzel (vagy kábelen bekötve) csatlakozik egy access pointhoz (wireless router), ami be van kötve a PC-be. A laptopon fut egy idõzítõ, ennek az értékét küldöm a PC-re adott idõközönként (a kívánt intervallum: 100 msec).

A PC-n nézem, hogy milyen adat és mikor érkezik, és az egyes beérkezõ adatok között eltelt idõt vizsgálom (csak mérési funkciók elvégzésére).

 

Vezetéken TCP/IP kapcsolatot használva:

Stabilan megy a számláló, de igazából nem tudja 200 msecnél gyorsabban küldeni az adatokat. Ha én 100 msecel küldök, akkor is csak 200 msecenként jön az adat, csak minden csomagban 2 értéket küld el.

 

Vezeték nélkül TCP/IP kapcsolatot használva:

A számláló nem stabil, indõnként hosszabb ideig nem jön adat, majd hirtelen beérkezik az összes kimaradt adat. Ugyanúgy legfeljebb 200 msec küldési intervallummal.

 

Vezetéken UDP kapcsolatot használva:

A számláló stabilan megy, ha kis intervallumot hagyok (pl. 20msec) akkor is szakadozásmentesen számol.

 

Vezeték nélkül UDP kapcsolatot használva:

Látszólag ugyanaz, mint vezetéken.

 

Megjegyzés: Delphi alatt készült mind a TCP-s, mind az UDP-s tesztprogram, TCP-hez a beépített TCP socket komponenst az UDP-hez fundamentals udp socket komponenst használtam.

A küldéshez egy külön szálon (time critical prioritással) egy multimédia timert kezelek le, ami elég pontosnak mondható. Sajnos viszont azt tapasztaltam, hogy az ablak nyitogatások és méretváltások befolyásolták az eredményeket. pl. megnyitok, vagy minimalizálok egy másik windows ablakot akár a vevõ, akár az adó oldalon.

Egyik fõ kérdésem, hogy ez hogyan küszöbölhetõ ki!?

 

A végleges alkalmazásban jelenleg egy olyan eszköz van a PC helyén, ami csak TCP/IP-t tud. Pontosabban egy ethernet soros átalakító, ezért elsõsorban, ha lehet TCP-vel oldanám meg. Másrészt a TCP egy beépített komponens, ezért azt szívesebben használnám.

Cél: vezetékmentes, stabil, kis adatcsomagok: néhány 100 bájt, gyors küldés: kb. 100 msec, kvázi real time mûködés.

Egyrészt hogyan állítható kisebbre a TCP minimum (re)transmit time intervall-ja, vagy akárhogy is nevezik, hogy akár 100 msec-enként lehessen küldeni adatot?

Hogyan módosíthatók úgy az accesspoint beállításai, hogy stabilabb legyen a mûködés? Vagy milyen egyéb beállításokkal lehet javítani a vezetékmentes kommunikáción?

Ha a TCP-n nem megoldható, akkor UDP-n szerintetek mehet-e? Elsõsorban a vezetékmentes hálózaton!

Mennyire stabil az UDP?

Visszatérve hogyan oldható meg Delphiben, hogy az adás (ez a legfontosabb), valóban real time mûködjön? Ez a timer vagy a TCP illetve UDP komponensek hibája?

A Delphi saját Timere egyébként használhatatlan (pl. addig nem fut le az esemény, amíg az ablak fejlécén nyomva tartom az egér bal gombát). Ha van megbízható timer kódotok, sokat segítenétek.

 

Várok mindenféle hozzászólást, ötletet!

Ha valami nem érthetõ kérdezzetek.

 

Köszi

Link to comment
Share on other sites

arpsoft

A különbség az UTP és a TCP protokoll között van. Az egyik szigorú rendben küldi a csomagokat, míg a másiknál nincs garantálva a túloldalon a csomagok helyes sorrendben történõ megérkezése.

Az UDP szigorú, a TCP nem. Ezért megy pl. az FTP UTP alapon.

Link to comment
Share on other sites

jiu88

Azt tudom, hogy mi a különbség a TCP és az UDP között. Azt nem tudom, hogy Delphiben hogyan változtathatók a TCP paraméterei, retransmition time, retransmition count, stb, ha ez egyáltalán lehetséges.

A másik kérdés, hogy hogyan lehet az, hogyha egy multimedia timert használok (ami C++-ból lett átírva Delphibe) time critical szálon futtatom és a timer eseményre elküldöm az adatokat TCP-n, vagy UDP-n, akkor ezt befolyásolni tudja, ha egy tetszõleges ablakot nyitogatok vagy csukogatok a Windowsban. Ha mondjuk soros kommunikációról van szó, azaz soros portra akarom kiírni ezeket az adatokat, akkor ez a hibajelenség nem jön elõ. Szinte 100%, hogy nem a timerrel vagy a szálkezeléssel van baj, hanem a TCP vagy UDP küldéssel (azért jó lenne, ha valaki tudna egy megbízható timert adni, mert azzal is kipróbálnám). Hogyan lehetne megoldani, hogy amit elküldök TCP-n, vagy UDP-n, az rögtön el is menjen, ne 200-250 msec múlva!

 

Ahogy már írtam a rendszerben egy Ethernet soros átalakító van (és én elvileg soros portot kezeltem le, de TCP-n ment a valódi kommunikáció). Ez baromi jól mûködött mindaddig, míg vezetékesen játszottam vele, de amint vezetékmentes hálózatot alkalmaztam nem lett stabil (pl. adatok vesztek el) és sokkal rendszertelenebbül jöttek az adatok! Egy mezei rádiós modullal összehasonlítva sokkal rosszabb eredményt mutatott (sajnos az a rádiós modul nem képes a kívánt adatmennyiséget ezen a sebességen átvinni, és a LAN-hoz sem illeszthetõ). Szóval a vezetékmentes hálózatra, eszközökre gyanakodtam elõször (még most is van kétségem). Rossz térerõ, rossz beállítások az access pointon stb, de miután mindent kiszûrtem, és sokat informálódtam, csak ezek után kezdtem vizsgálni azt, hogy TCP-n elvileg nem is mûködhetne (bár eddig mûködött, csak kábelesen!!!). Aki tud a kérdéseimre kérem válaszoljon, vagy ha tudtok olyan komponenseket (timer, TCP, UDP), amik megbízhatóan és real-time mûködnek!

 

Köszönök minden segítséget és információt!

 

 

 

 

 

Link to comment
Share on other sites

jiu88

Rájöttem, hogy mi okozta azt, hogy a Windows ablakok le-fel nyitása késleltette az adatok küldését. Az történt, hogy a timer eseménybe minden hívásnál egy editboxba beírtam, hogy mit küldök. Mivel egy VCL komponensrõl van szó, ezért valahogy ennek a kezelésével függhet össze. Miután ezt megszüntettem, rögtön megszûnt a hiba is. Így már valóban real-time mennek az adatok.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...