Hali !
A 1159-os CODER-ban
Pentek, 200. aprilis 27.-an irta  :
>Lehet, hogy elkapkodom kozepiskolaskent, de a szamtechtanarom
>allandoan azt mondogatja, hogy aki kodolasbol akar megelni,
>annak specializalodnia kell nyelvre es szakteruletre.
>En a c-re es a c++ra akarok specializalodni, de szakteruletrol
>fogalmam sincs mire erdemes.
>Erdekel a halozat programozasa, de azt mondjak oda inkabb javasok
>kellenek. Egyik haverom hangkartyakat berhel, de az nem erdekel.
>Tudnatok olyat javasolni ami fontos, magyarorszagon kevesen
>csinaljak, es van jovoje?
Hat igen. A polihisztorok ideje elegge lealdozott.
A nyelvi specializalodast illetoen en nem mondanam, hogy ennyire erdemes
kotodni egy nyelvhez.
Egy nagyon regi "szakszoveg" :-) szerint " Az Igazi Programozo barmilyen
nyelven kepes Fortran programot irni !"
En inkabb mondanam azt. hogy a programnyelvek olyanok, hogy ha 4-5
nyelvet mar megismertel, akkor azutan mar barmelyiket nagyon gyorsan meg
tudod tanulni.
A C++ melle peldaul nem hiszem hoyg bonyolult lenne megtanulni a Java-t.
(ez egy felteves, mert en pont nem ebben az iranyban mozgok)
A nyelvi "latokor" kiszelesitese mellett szolo masik erv, hogy egy uj
munkahelyen nem te fogod meghatarozni, hogy miben keszuljon a program,
hanem megmondjak, hogy "itt ezt, meg ezt hasznaljak".
(Persze eleg sok helyen keresnek C++ programozot, de ezzel mindenkeppen
szukul az elhelyezkedesi lehetoseged)
A szakterulet eseteben osztom a tanerod nezetet. Itt mindenkeppen erdemes
specializalodni.
En peldaul az ugyvitel teruleten mozgok tobbnyire, ahonnan neha
"kirandulok" valamilyen rendszerkozelibb teruletre.
Ha kello elhivatottsagott es nagymennyisegu tanulasi vagyat erzel
magadban, akkor a halozati es/vagy mobil kommunikacio iranyvonalat tudnam
neked javasolni mint szakterulet. Ebben nagy igeny van __jolkepzett__
programozokra, es orult penzeket lehet vele keresni. (ahogy en hallom)
__Viszont__ ezen a teruleten ~2-3 evente ujratanulhatod a szakmadat, mert
gyorsan avul a tudas, a technologiaval. Szoval ez a terulet a
megszallottaknak valo. (IMHO)
--
Udv : Csiszar L.
http://www.stadium.hu/szt
|
Hello
A mulkor kerdeztem, hogy hogyan lehetne megtudni egy gep IP cimet,
egyszeruen es praktikusan.
Egy jvaslat erkezett, amit azonban sajnos nem tudtam felhasznalni,
mert a PowerBuilderbol amiben hasznalni akartam, nem letezik a
megoldashoz szuksegeshez meg csak hasonlo fuggveny sem.
Iyg onerobol kellet nekiallani a keresesnek.
Ennek alapjan egy ketlepeses metodust sikerult kiotlenem.
A registry-bol probaltam kiolvasni a szukseges adatokat.
Amit talaltam W2000 es NT4 eseten mukodokepes, W9x-en nem tudtam
megnezni, mert az nincs korulottem.
Az IP cim meghatarozasa a registrybol :
HKLM\system\CurrentControlSet\services\tcpip\linkage kulcs Bind alkulcsbol
megtudhato a kartya neve, ha az elejerol elhagyjuk a "device"
szoveget.
Utana a ...services\"kartyaneve"\parameters\tcpip kulcs IPAddress alkulcs
erteke az IP cim
Persze ha tobb halokartya van a gepben, az bonyolithatja a helyzetet,
de a kiindulasi pont tovabbra is lehet ez.
Sajnos azonban ez szamomra csak egy elmeleti lehetoseg maradt, mivel a
PB volt olyan kedves, hogy a RegistryGet() fuggvenyt rosszul
implementalja, es gyakorlatilag csak STRING tipusu kulcsok eseten
mukodik jol. Ha Binary tipusu kulcsokra alkalmazom (es a fentiek sajna
ilyenek) akkor az istennek nem tudom visszakapni az ertekeit, hiaba
adok neki BLOB vagy barmilyen mas valtozot. Jellemzoen csak egy
Dr.Watson lett a vegeredmeny.
Ha esetleg volna itt komoly PowerBulideres, es volna kedve kiprobalni,
hogy nala hogy mukodik a dolog, orommel vennem a segitseget.
Azt kernem, hogy ha megoldasi otletet kuld, akkor elotte probalja ki,
hogy tenyleg mukodik-e, mivel a doksit en is olvastam, epp csak a
fuggveny nem olvasta a doksit, hogyhogy kellene mukodnie.
--
Udv:
Csiszar L. mailto:
www.stadium.hu/szt
|
Hi!
>HC> A jelenseg az, hogy 1 mp alatt kb 10-15-szor kuldok 32 bytot es szinte
>HC> teljesen megakad tole a gep. Az MSDN-ben talaltam egy fel mondatnyi
>HC> megjegyzest, hogy ha tul sokat kuldok, vagy a masik oldalon nem
>HC> tudjak fogadni, akkor a send() addig var, amig nem sikerul. Most egy
>HC> 100Mbites halon nem tunik tul soknak az a 3-400 byte/sec.
Azért számolj utána mégegyszer úgy, hogy végiggondolod hogyan történik a
protocol rétegben az üzenet lefelé haladása közben az enveloping. a 32
bájt belekerül egy TCP csomagba (+20 byte), az belekerül egy IP csomagba
(+20 byte), ez pedig belekerül egy ethernet frame-be (+18 byte). Az
összesen 90 byte. 10-20-al beszorozva ez 900-1800 byte, a te általad
mondottak 3-4 szerese.
Ez 100 Mbiten tényleg nem túl sok, de real-time mérő programoknál, ahol az
adat forrás nagy frekvenciával "kis" méretű csomagokat generál terhelt
hálózaton, ott ez már számíthat.
Hogy miért ilyen lassú, annak sok oka lehet. Magasabb szintű: a windows
protocoll stack tökéletlensége (pár ponton nem tartják tiszteletben a
TCP/IP RFC-ket), vagy különböző verziójú/fajtájú protocol stackek
együttműködési problémája. Még magasabb szinten lehet tökéletlen az a
szubrutinrendszer, amin keresztül ezt használod a te programodban. Esetleg
valamire nem figyel oda a te programod (ez gyakori eset).
Vagy alacsony szinten is lehetnek gondok: kiforratlan ethernet kártya
driver, vagy maga az ethernet kártya (lásd NE2k). Milyen 100Mbites kártyád
van? Ugyanis 10Mbitesek között valódi DMA módot csaka DEC Tulip és
bizonyos AMD chipes kártyák bírnak, ezek valók nagy terhelés esetére. És
bizony 100Mbites kártyák között is vannak NE2k leszármazottak!
Valószínűleg a te esetedben nem ez a probléma, de azért nézz körbe, hoyg
melletted nem tükrüztek-e éppen páran egyes site-okat az alhálón, mert
azért az betelíthet 100Mbitet is akár.
Ha az érintett géppel FTP vagy más kapcsolaton keresztül képes vagy nagy
sebességet is elérni, akkor sajnos valahol a te progid környékén van a
gáz.
>HC> A socket MessageHandler-eben nem nagyon foglalkoztam az FD_WRITE esemennyel
>HC> Lehet, hogy ez a nyitja? Mondjuk gyujtom egy memoriablokkban, hogy
>HC> miket kell kuldeni, es ha jon egy ilyen esemeny, akkor elkuldok
>HC> annyit, amennyit lehet.
>HC> Lehetseges, hogy igy kell?
Te csak nyugodtan írjál a socket descriptorba. A win belső bufferei és a
TCP/IP stack flow controllja elintézi a dolgokat.
Az FD_READ-et pedig használd arra, hoyg figyeled van-e válasz a
túloldalról.
>hat, a winsock lelkivilaga elottem egy nagy rejtej (halistennek nem
>win alatt nyomulok;)... de amit eszrevettem anno, amikor a tcp-met
TCP/IP stacket írtál? (nem akarok kukacoskodni, de akár ez is lehet)
>csinaltam az a kovetkezo, es szerintem ez lehet a dolog nyitja...
>van ugye ez a delayed ack nevre hallgato csoda, ami annyit tesz, hogy...
>ugye a sima tcp kapcsolat ugy nez ki, hogy van ugye a kuldo, az kuld,
>mint az istenveres... van a fogado, ami fogad, es minden fogadott (es jo)
>tcp csomag utan azt mondja, hogy koszi, megjott... (ack-ot kuld;)
>a delayed ack mint a neve is mondja, annyit tesz, hogy ne terheljuk
>tul a halot, a kuldo ugyancsak kuld, csak kuld, de a fogado csak
>minden 2-3k megkapasa utan mondja azt, hogy koszi szepen, megjott....
>(okes, akkor is ackol, ha mondjuk egy csomagot ketszer kap meg...
>de ezekbe az extrem esetekben ne menjunk bele;))))
Szerintem tisztázzuk, hogy ugye ez a TCP protocollon belül történik amit
te leírsz (lehet, hoyg nem mindenkinek világos).
>ha megadott ideig (anno a win es a lin is 1 ms-et hasznalt:)
>nem jonne meg a kello 2-3k, akkor pedig leackolja csak ugy ala
>nature;) ez eddig szep meg jo, mert ugye kevesebb csomag lesz
Azt mondod így működik a windózer TCP/IP stack? Kilóra méri a dolgokat? Ez
durva lenne. Egyébként ha jól tudom az ACK mindenképp egy másik csomagra
válasz, így egy ilyen árva "a la nature" ACK eléggé "break"-elné a többi
protocol stack-et. De nem értek túlzottan a TCP/IP flow control
mechanizmusaihoz, amiből bizony jó pár van. Ami a TCP/IP-nek elég rossz,
az inkább a csomagvesztés (lásd. TCP/IP teljesítménye erősen leeshet
wireless alkalmazásoknál, illetve a slow start miatt periodikus
jelenségek alakulhatnak ki, stb.)
>a halozaton, de ez a kis csomagok egyiranyu aramlasat rohadtul
>megneheziti... probald ki (egy probat meger;) hogy minden egyes
>ilyen kicsi csomag vegere tegyel kitolto 'A'-kat... ez azert lesz
>jo, mert egyreszt fel fog toltodni a tavoli gep annyira, hogy
>kuldjon egy ackot... masreszt, a 100mbps halonak kurvara mindegy,
>hogy 15*30b, vagy 15*3k..;))))
Szerintem ez fölösleges. csak növeli a terhelést. Igaz, jól tömöríthető,
de minek.
>masreszt, ha ugyanolyan karakterekkel
>toltod fel, (vagy csak 0, vagy csak 1, vagy csak A vagy csak Z...)
>akkor ezt ugye a modem jol tudja tomoriteni... talan az A betu
Hát a modemnél aztán pláne nem mind1 a dolog. terhelés.
>ha ez a tipp bejon, es ez tenyleg segit, akkor viszont kell majd
>tegyunk egy nagyon szomoru megallapitast, hogy a winsock nem
>a tcp.windowsize-t figyeli, hanem azt mondja, hogy mittomen 16
>csomagnal nem hajlando kint tartani tobbet.... ja, amire nem tertem
Hogyhogy "kinntartani"? Ezt nem értem. Egyébként itt pont azt mondod, hogy
a windóz _nem_ a mennyiséget figyeli (mint korábban 2-3k-t mondtál), hanem
a darabszámot. Magyarázz léci (megint nem kötekedésből mondom).
>(ui: kb a fentiek emiatt szoktak az ftp-t is lassunak titulalni
>kis fileok atvitelere....;))))
Az ftp-nél szerintem nem fordul elő ilyen probléma, amit korábban leírsz
(sok de pici csomag), ott pont mennyiségeket szoktak átvinni, és bizony
repülnek az 1500 byteos rakományú ethernet csomagok. De ha tovvább
indokolsz, elhiszem.
>a fentiek alapjan valoszinuleg megoldas lenne a problemadra,
>ha nem cel, hogy _azonnal_ megerkezzen az adat a tuloldalra....;))))
A te általad leírt tippnek az a célja, hogy minél hamarabb megérkezzen az
adat applikációs szintre, azaz hogy a TCP/IP stack a saját buffereiből
minél hamarabb kikerüljön a hálóra, a helyi stack pedig minél hamarabb
kiböfögje az alkalmazásunknak. Csak az eljárásnak nem vagyok meggyőződve a
sikerességéről/alapjairól. Ha valaki kipróbálja léci számoljon be.
>de amugy az is jo megoldas lenne, ha tenyleg csak ilyen kis
>semmi adatokrol van szo, hogy atirod az egeszet udp-re...
>okes, ez bonyibb, mert figyelned kell, hogy a tuloldal
>megkapta-e, de a csomagok sorszamozasaval ez sem annyira
>egbekialtoan bonyolult feladat....
Az UDP-nek csak akkor van értelme, ha nem baj, hogy ha esetleg elveszik a
csomag, vagy más sorrendben érkezik meg (ez persze csak nagy terhelésnél
jön elő általában). Ha ezt nem viseli el az alkalmazás, akkor célszerűbb
inkább TCP-t hasznáni, mint saját hack-et írni UDP fölé, mert a TCP egy
jól letesztelt dolog, kevesebb a hibalehetőség, és garantált átvitelen
kívül sorrendhelyességet is biztosít. Persze minden az adatforrás és a
feladat jellegétől függ.
Mellesleg a te általad leírt jelenség ha igaznak bizonyul, akkor az
valószínűleg UDP-nél is igaz kell legyen, mert ugyanarról a protocol
stackről van szó. Az IP szint ráadásul ugyanaz, igaz, az UDP-t
kifejezetten streaming, real-time jellegű feladatokra tervezték.
0.1 ms-os késleltetéshez hozzáfűznék
Annak aki pedig éppen a 0.1 ms-os periódusú programot próbál írni azt
üzenem, hogy megközelíti az operációs rendszer által alkalmazott
ütemezési egységet (amit a processz/task/thread ütemező mag használ,
NT-ben quantum), ami alá nyilván nem lehet lemenni. Az NT (ha jól
emlékszem W2k alatt írod, ami NT alapú) _teljesen_ más ütemezésű van, mint
a Win9x-nek!!!. Ezért mielőtt nagyon beleélnéd magad, írd meg a mostani
felfedezéseden alapuló timer teszt progit, és próbáld ki a Win9x-es gépen.
Így elkerülheted azt, hogy sok programozás után pórul járjál, és még
időben elmondhatod a megrendelődnek, hoyg ilyen célra ne Win-t használjon.
A linux ilyen szempontból talán jobb, mert noha annak a is van időbeli
felbontási határa, de ilyen feladatra egyértelmű, hogy jobb. Még jobb, ha
megpacheled rt-linux patch-el, ami ezt a felbontás jól lecsökkenti, és a
doksiban található módon real-time rutinokat írhatsz. Igazából nemtom ezek
mennyire real-time-ak, azaz: milyen garanciát adnak arra, hogy a te
processzed bizonyos időperiódusonként meghívódik (pont ez a te problémát,
hiszen nem terhelnéd le a nnyira a procit, de sűrűn szeretnéd megkapni a
vezérlést). Még jobb ennél a QNX, amelynek jellege linuxhoz hasonló, de
egyébként más, mert egy ízig-vérig RTOS. Ipari rendszerekben alkalmazzák
RT célokra, szóval tuti.
Hát emberek, ekkora lett ez a levél. Néha szájmenésem van.
--
tocsa
---
| email:  ,  |
| homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa |
---
|
