> Az a kerdesem, hogy van-e arra lehetoseg, hogy az Excel 5.0-ban
> olyan fuggvenyt, eljarast, makrot, stb. irjak, ami a kesobbi
> valtozatokban nem, vagy hibasan mukodik? Ha van, mi ez, hol nezhetek
> utana? Esetleg az Excel valtozat lekerdezese megoldhato-e?

Excel verzió lekérdezése:
Application.Version
Ez egy stringet ad vissza, nálam például "8.0a" (97-es Excel).

Egyébként mi értelme van a későbbi verziókra blokkolni a rutint?

Feri

tisztelt HIX CODER!

>hat, a winsock lelkivilaga elottem egy nagy rejtej (halistennek nem
>win alatt nyomulok;)... de amit eszrevettem anno, amikor a tcp-met
HC> TCP/IP stacket írtál? (nem akarok kukacoskodni, de akár ez is lehet)
;) igen, en irtam, hogy az _eredeti_ kerdezo irt-e, arrol
gozom sincs... de valoszinusitem a nemleges valaszt...;))))))

[delayed ack jelenseg lin/win tcpip stackben]
igen... hatarozottan allitom (0.5-1 eves meresi eredmeny!:) hogy a win es
a lin is ugyanugy teszi a dolgat... azaz, _fogadasnal_ ugy van vele, hogy
fogad, fogad... amit kapott, azt rogton oda is adja a felsobb retegeknek,
de meg mindig fogad... ha 1 masodperc alatt nem kap meg x (x>1k) mennyiseget,
akkor 1 masosperc utan kuld egy ackot... de ha 1 masodperc alatt elegge sokat
kapott (>1k) akkor meg az egy masodperc letelte elott elkuldi az ackot a
csomagra... de!! pl ha ugyanazt a csomagot ketszer kapja meg 1 masodperc
alatt, akkor is rogton ackol (mert arra gondol, hogy a tuloldal timeoutra
futott!:)        (lasd: masik levelemben az elso tablazat... 199sor/nap;)))

remelem igy mar vilagos.... a valasz ezen reszet akar kesz tenynek is veheted
(ha nem hiszed, merd ki magad;) de en ezt lattam a sajat stack irasa kozben..
(ezert, hogy rogton ackot kapjak, opcioba lehet nalam tenni, hogy az 'utolso'
csomagokat automatikusan ketszer kuldje el....) hmm.. amugy a teszt elvegzese
nagyon egyszeru, betelnetelsz valami protokollba, ami nem echoz (tehat _ne_
telnetbe, hanem pl ftp, pop3, smtp, http, vagy ami jolesik;) es kuldozgetsz a
betuket, es nezed, hogy mennyi idonkent kapod meg az ackot...
most neztem lin alatt, ugy latom lecsokkentettek, most mar csak fel
masodpercet varakozik, tehat az elso peldaban a akar at is irhatnam...;)))
de nem irom, mivel nem mertem ki pontosan, igy nem tudom, hogy mennyit, igy
szemre fel masodperc...;))))

HC> Azt mondod így működik a windózer TCP/IP stack? Kilóra méri a dolgokat? Ez
HC> durva lenne. Egyébként ha jól tudom az ACK mindenképp egy másik csomagra
HC> válasz, így egy ilyen árva "a la nature" ACK eléggé "break"-elné a többi
HC> protocol stack-et. De nem értek túlzottan a TCP/IP flow control
nos... levileg tenyleg minden csomag utan megy ack... de a delayed
ack lenyege eppen az, hogy pl a fenti tesztet amikor csinaltam,
eppen fel perce, akkor minden masodik a-betum utan jott az ack....
amugy az 'a-la-nature' ack nem teljesen ertem, miert breakelne es
mit....;))) pl en a stackemben ugy csinalom, hogy ha uresjarat
van, akkor is minden percben kuldom egy acket... biztos ami
biztos...;))))) ha menet kozben a dialup lehalt, es jott hejette
egy masik, akkor sem fog bent ragadni tul sok idore a handle...;))))
(persze van timeout is a forgalom fuggvenyeben, de azert csak gyorsabban
kiderul igy, a minden percben kuldott ack-el, mint anelkul....;))))
(es mint tudjuk, a handle bizony draga mulatsag, jobb sporolni vele;)

HC> mechanizmusaihoz, amiből bizony jó pár van. Ami a TCP/IP-nek elég rossz,
HC> az inkább a csomagvesztés (lásd. TCP/IP teljesítménye erősen leeshet
HC> wireless alkalmazásoknál, illetve a slow start miatt periodikus
HC> jelenségek alakulhatnak ki, stb.)
;)))) nos, az adatvesztes tenyleg egge gaz a tcpnek, de azert annyira
nem;)))) gondolj csak bele... kint tartasz a halozaton kb 8k-t...
okes, abbol elveszik egy, akkor azt a 8k-t ujra kell kuldeni...
de hamar kiderul, ami beborul.... pl en is, a lin is, meg a win is
ugy csinalja, hogy menet kozozben szamolom a timeoutot... (es itt
akar van slow start, akar nincs, a modszer tok ugyanaz.. a slow start
csak annyit csinal, hogy egy hibajavitas (loss recovery;) utan visszaesik
a kinntarthato csomagok szama (a tx window size;) es minden egyes ack-al
novelem addig, ameddig el nem erem a maximumot... tehat ennek vegulis
jelentosege csak a gyakran zavaros vonalon van.....;))) egy ritkan
zavaros vonalon ez a slowstart tenyleg csak hatraltat, de azert
artani nem art, ha be van kapcsolva... soha nem lehet tudni, hogy
milyen vonal van a tulvegen;)))))
szoval.... most irom slow start nelkul a peldat, de ha azert biztos
ami biztos, majd lesz folyamatabra slowstart-ra, es normalra;)))))
szoval indulas (vagy recovery:) utan ezek jatszodnak le...
timeout vissza 20sec re, retry csokken egyel;))))) kikuldom az elso
4k-t... megjon a valasz... az eltelt idohoz hozzaadom a sajat kis
konstansomat (1 sec;) es ez lesz az uj timeout... kikuldom az ujabb
4k-t... megint jon valasz, megint kiszamitom az uj timeoutot..
egeszen addig, amig van mit kuldeni...
minden ackra igaz, hogy ha adatot ackol, akkor kiszamitom az uj
timeoutot, es a retry-t beallitom konstansbol 20-ra....;))))
minden timeoutra igaz, hogy visszamegyek a legelejere... azaz
timeout=20, retry csokken... ha retry=0, akkor gaz van...;)))))

>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..;))))
HC> Szerintem ez fölösleges. csak növeli a terhelést. Igaz, jól tömöríthető,
HC> 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
HC> Hát a modemnél aztán pláne nem mind1 a dolog. terhelés.
;)))) igen, de mondom, ha van mnp (a mai modemekben mar van
hardver szinten _is_ tomorites) akkor tok mindegy, vegulis
nem lesz semmivel sem lassabb... probald csak ki, fogsz ket
modmet egymassal szemben, csonalsz egy 2400/v42bis kapcsolatot,
es kuldesz mint az istenveres.. eloszor random adatot...
az eredmeny ugy 240-250 cps lesz... aztan kuldesz csupa
ugyanolyan adatot... pl csak a betut.. ami a csovon kifer...
es meg fogod latni, hogy az atereszto kepesseg akar 5000 cps
fole is mehet!!!!! tehat ennyire mindegy a modemnek, hogy
ha kitoltes van a csomagjaid vegen!!! (ha nem tudsz kezzel
kuldeni, akkor csinalsz ftp kapcsolat ket gep kozott modemmel,
leftp-zel egy binaris filet, es egy csupa A betus filet,
es amulsz, hogy mennyivel jobban jonnek az A betuk.....;)))))
(ha wined van, akkor hiperterminal, Zmodem, es mar mehet is....;))))

>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
HC> Hogyhogy "kinntartani"? Ezt nem értem. Egyébként itt pont azt mondod, hogy
HC> a windóz _nem_ a mennyiséget figyeli (mint korábban 2-3k-t mondtál), hanem
HC> a darabszámot. Magyarázz léci (megint nem kötekedésből mondom).
;)) igen... a fenti par sort mint olvashattad, felteteles modban
probaltam irni... tehat 'HA ez tenyleg segit, AKKOR'....
de amugy szerintem nem ellentmondas, mert a fenti resznel
(most mar) kihangsujoztam, hogy a fogadas (rx) az tutira
1k+1s szabajt koveti, es most hogy a kollega felvetette
ezt a problemat, a gyanu mar megvan, hogy a tx-nel pedig
nem byte, hanem csomag szamit.... de ez most meg csak
egy gyanu, nagyon remelem, hogy a kollega azert nem veti
el ennyire egyertelmuen a valaszomat, es kiprobalja,
hatha bejon....;)))))
mondjuk a logikanak teljesen ellentmondana a dolog,
hogy miert is tartana kulon csomagokban a cuccost
a kimeno soraban a winsock.... de soha nem lehet tudni...
(talan ennyire ugyeltek az rfc-k intelmeire, hogy legyunk
kovetkezeetsek, es ezert ha egyszer mar elkuldtek egy
csomagot, akkor mindig annyi byte lesz abban a franya
csomagban, es az uj adatokat kulon csomagba teszik?;)))))
de mondom ujra...
a fent leirt fogadasi 'trukk' (realtime dolgoknal bug:) tenyleg igaz....
                                                     (rfc813/11.o)
a lent leirt kuldesi 'bug' csak gyanu.....

>(ui: kb a fentiek emiatt szoktak az ftp-t is lassunak titulalni
>kis fileok atvitelere....;))))
HC> Az ftp-nél szerintem nem fordul elő ilyen probléma, amit korábban leírsz
HC> (sok de pici csomag), ott pont mennyiségeket szoktak átvinni, és bizony
HC> repülnek az 1500 byteos rakományú ethernet csomagok. De ha tovvább
HC> indokolsz, elhiszem.
hat hogyne... kepzelj csak el egy 200 byteos filet.... mondjuk valami
emlekezteto, ami kint van mondjuk a vilag masik vegen....;) ehez kepes
te itthon ulsz, es kell neked a file... (lasd a masik levelben;)

nos, valoban nincs sok kicsi csomag a halon?????;)))))))))))))))))))))
18 kicsi csomag (csak parancsok, es valaszok;) a sin, fin, es csak a
sima ack csomagokrol nem is beszelve....;)))))

>a fentiek alapjan valoszinuleg megoldas lenne a problemadra,
>ha nem cel, hogy _azonnal_ megerkezzen az adat a tuloldalra....;))))
HC> A te általad leírt tippnek az a célja, hogy minél hamarabb megérkezzen az
HC> adat applikációs szintre, azaz hogy a TCP/IP stack a saját buffereiből
HC> minél hamarabb kikerüljön a hálóra, a helyi stack pedig minél hamarabb
HC> kiböfögje az alkalmazásunknak. Csak az eljárásnak nem vagyok meggyőződve
HC> a sikerességéről/alapjairól. Ha valaki kipróbálja léci számoljon be.
;))) igen, tenyleg az a celja a tippnek, hogy a win minel hamarabb
tuladjon a csomagon, es ami a lenyeg, hogy minel hamarabb meg is kapja
a valasz ackot... mondom a tipp arra a feltetlezesre epul, hogy neadj
isten a win kicsit tulsagosan is koveti ebben az egy temaban az rfcket...

[udp csomagok + sorszamozas]
HC> Az UDP-nek csak akkor van értelme, ha nem baj, hogy ha esetleg elveszik a
HC> csomag, vagy más sorrendben érkezik meg (ez persze csak nagy terhelésnél
HC> jön elő általában). Ha ezt nem viseli el az alkalmazás, akkor célszerűbb
HC> inkább TCP-t hasznáni, mint saját hack-et írni UDP fölé, mert a TCP egy
HC> jól letesztelt dolog, kevesebb a hibalehetőség, és garantált átvitelen
HC> kívül sorrendhelyességet is biztosít. Persze minden az adatforrás és a
HC> feladat jellegétől függ.
igen, ez igaz... tenyleg fugg a feladat milyensegetol... csak errol mint
altalaban lenni szokott, gozunk sincs.... lehet, hogy minden kis 30 byte
nagyon fontos, es idoben oda is kell ernie, akkor tenyleg nincs mas, mint
a fill;))) ha nembaj, ha elveszik par, mert ugyis annyi van beloluk, mint
a franc, akkor az udp sorszamozas nelkul, de ha van egy kis szorakozni valo
ideje a kerdezonek, akkor az udp sorszamozassal egy erdekes, es nem tul
nehez kihivas...

HC> Mellesleg a te általad leírt jelenség ha igaznak bizonyul, akkor az
HC> valószínűleg UDP-nél is igaz kell legyen, mert ugyanarról a protocol
HC> stackről van szó. Az IP szint ráadásul ugyanaz, igaz, az UDP-t
HC> kifejezetten streaming, real-time jellegű feladatokra tervezték.
az igaz, hogy ugyanaz a protokol stack, csak eppen az udp-ben nincs
hibajavitas, tehat a stacknek nem kell eltarolnia az infokat ujra
kuldes celjabol, hanem amint kitette oket az ip fele, rogton freemem
a buffernek, aztan csokolom, mar le is tudta az az udp csomagot...
hehh? :) tehat attol, hogy a _ESETLEG_ a tcp tx sor csomagban van
limitalva, es nem byteban, ez fuggetlen az udp-tol..

na tovabbi jo kodolast mindenkinek.... Mc

tisztelt HIX CODER!

HC> Hogy miért ilyen lassú, annak sok oka lehet. Magasabb szintű: a windows
HC> protocoll stack tökéletlensége (pár ponton nem tartják tiszteletben a
HC> TCP/IP RFC-ket), vagy különböző verziójú/fajtájú protocol stackek
HC> együttműködési problémája. Még magasabb szinten lehet tökéletlen az a
HC> szubrutinrendszer, amin keresztül ezt használod a te programodban. Esetleg
HC> valamire nem figyel oda a te programod (ez gyakori eset).
HC> Vagy alacsony szinten is lehetnek gondok: kiforratlan ethernet kártya
HC> driver, vagy maga az ethernet kártya (lásd NE2k). Milyen 100Mbites kártyád
HC> van? Ugyanis 10Mbitesek között valódi DMA módot csaka  DEC Tulip és
HC> bizonyos AMD chipes kártyák bírnak, ezek valók nagy terhelés esetére. És
HC> bizony 100Mbites kártyák között is vannak NE2k leszármazottak!
hmm... ebbe a halokartya dologba ne menjunk bele, de!!
a te altalad leirt kartyak igy mukodnek:
ne1000/2000 is mindketto 32/64k belso memoriaval dolgozik...
ebben te felallitasz egy kicsi tx queut (en 2-3 csomagnyit
szoktam;) es egy istenes meretu rx queut... ezeket a kartya
magatul kezeli.... neked van egy pointered, hogy melyik
(ugy remlik) 256byte blokk a legutoljara erintett... ebbol
tx.q. eseten tudod, hogy elkuldte-e a kartya, rx.q. eseten
pedig azt, hogy jott-e csomag... ezen felul minden csomagnak
van fejlece, de ez most reszletkerdes... na... szoval
a kartya dolgozik mint a gep, kozben te beadsz a kartyanak
egy pointert, hogy honnantol szeretned olvasni a kartya belso
ramjat, es mar szedheted le egy portrol... persze mindkezoben
ha jon egy csomag, azt a kartya beteszi az rq.q-ba, ha eppen
van neki hely... (bovebben, www.national.com, ns8390 doxx)
tehat egy jol megirt driver ki tudja hasznalni a kartya
hatarait... ezt igazoljak az eredmenyek is, akar meg egy
win is eleg a 1mb/s sebesseghez (ftp-vel) egy ures halon!!
ehhez kepes csak ujitas az smc (es wd) altalal kitalalt
dolog, hogy a kartya belso ramjat kimappelik valahova
a valos cimtartomanyba, es igy nem kell portio-val elerni
a cuccost, hanem pl 0d000:0 cimen van a kartya memoriaja...
a dec tulip egy 100mbps-es pci kartya, dma-rol szo sincs,
ez egy busmaster kartya... ehez kivetelesen nem a www.dec.com
cimet tudom ajanlani mivel az mar nem supportalja a kartyat,
hanem pl a www.mx.com (talan?:) ok gyartanak egesz jo klonokat...
az amd lance karyak ugyan isa-s karyak es van tobb valtozatuk is,
de mar a legregebbi csipjeik is kepesek voltak busmaster uzemmodra!!!
igen, a busmastering nem pci talalmany, a lance csipek is azok voltak!!!
ami az mx (dec tulip) csipet illeti, nekem 11.5 megat hozott 100mbps
halon, a dec csipek is hoztak a maguk 1mb/sec-et...
ami a ne2000/pci/100mbps kartyakat illeti, ezekkel tenyleg gaz van,
de nem a ns8390 miatt, hanem azert, mert az x86 nagy aldasa a portio,
olyan lassu, mint a franc...;))))))))) (ergo, a 100mbps eleresehez
mar tenyleg kevesnek bizonyult a port io.... amikor a 3com 905A
(nem busmaster!) kartyat probaltam 100mbps-en portio modban, hat tenyleg
elegge gyer, 8 mb/s sebesseget mertem!! de ha ne2k alat azt erted,
hogy egy katya rtl8139 csipszettel, akkor azt kell, hogy mondjam,
a ns8390 utan az egyik legjobb csip a vilagon!!! vegre egy szabvany
csip, gyors, jo, viszonylag megbizhato... csak dicserni tudom, hogy
sok karyyagyarto hasznalja.... szinten egy busmaster csip, egesz ugyes,
lehet daraboltatni a csomagokat, szoval tenyleg nagyon ott van...

de ugy egyaltlan... azt a hidelemet, hogy van szar, es van nagyon
pepec halokartya, el lehet szepen lassan felejteni... ez regen sem
volt igy... a gyartok azert szart ritkan adtak ki a kezukbol...
(legalabbis ha halokartyarol van szo, akkor ez igaz!:) amiven en
talalkoztam, mindegyikkel ki lehetett hozni a drot maximum sebesseget...
a kulonbseg csak a programozas egyszerusegeben, es egyebekben rejtozott..
az egyebek alatt azert kiternek par dologra.... pl abban, hogy hogyan
kezeltek a sollision, es egyeb trefas esemenyeket... pl nekem ebbol
a szempontbol a ns8390 utan tenyleg az rtl8139 tetszett a legjobban,
mert ezek a kartyak tulnyomo tobbsegevel ha mindketto full tx-en volt,
kb egyenlo aranyban osztoztak a savszelessegen, csomagvesztes nelkul...
ezzel szemben az agyondicsert 3c905A-B-C nekem ugy lefogta az rtl csipjeimet
(ha collision volt, akkor nem vart, mint ahogy az a standardban van,
hanem rogton ujra probalt kuldeni!) hogy hiaba volt a hubon 4 rtl,
es egy 3c, megis a 3c vitte a savszelesseg 99%-at, ami azert elegge
gaz, ha a router sem tud szohoz jutni egy kedves szerver miatt!!!:))))

na tovabbi jo kodolast mindenkinek... 

tisztelt HIX CODER!

a peldak 0.5 sec utazasi sebesseget, es 500 tcp max frame
meretet teteleznek fel... (igy konnyebb leirni a peldat... a
valosagban ez 56k dialupnal 1500 byte, es 0.2s, de ezek csunya
szamok.... pfuj;))))

delayed ack rx, akarmilyen tx:
---
ido         win/lin rx                           valami mas tx
0:0:0.0                              <--  seq=0, ack=0, len=12
0:0:1.0     seq=0, ack=12, len=0 -->
---
ido         win/lin rx                           valami mas tx
0:0:0.0                              <--  seq=0, ack=0, len=12
0:0:0.1                              <--  seq=0, ack=0, len=12
0:0:0.2     seq=0, ack=12, len=0 -->
---
ido         win/lin rx                           valami mas tx
0:0:0.0                              <--  seq=0, ack=0, len=600
0:0:0.1                              <--  seq=600, ack=0, len=600
0:0:0.2     seq=0, ack=1200, len=0 -->
---

nem slow start tx, (rfc szerinti) azonnali ack rx:
---
ido         rx                            tx
0:0:0.0                           ------  timeout=20, retry=20
0:0:0.0                              <--  seq=0, ack=0, len=500
0:0:0.0                              <--  seq=500, ack=0, len=500
0:0:0.0                              <--  seq=1000, ack=0, len=500
0:0:0.0                              <--  seq=1500, ack=0, len=500
;ezen a ponton eljutottunk oda, hogy 2k kint van a halon ackolatnalul....
;innentol ez mar a rendes 2k-s window meretu mukodes....;))))))
0:0:0.5      seq=0, ack=500, len=0 -->
0:0:1.0                           ------  timeout=1+1
0:0:1.0                              <--  seq=2000, ack=0, len=500
0:0:1.0     seq=0, ack=1000, len=0 -->
0:0:1.5                           ------  timeout=1+1
0:0:1.5                              <--  seq=2500, ack=0, len=500
0:0:1.5     seq=0, ack=1500, len=0 -->
0:0:2.0                           ------  timeout=1+1
0:0:2.0                              <--  seq=3000, ack=0, len=500
0:0:2.0     seq=0, ack=2000, len=0 -->
0:0:2.5                           ------  timeout=1+1
0:0:2.5                              <--  seq=3500, ack=0, len=500
---

slow start tx, (rfc szerinti) azonnali ack rx:
---
ido         rx                            tx
0:0:0.0                           ------  timeout=20, retry=20, txmax=500
0:0:0.0                              <--  seq=0, ack=0, len=500
0:0:0.5      seq=0, ack=500, len=0 -->
0:0:1.0                           ------  timeout=1+1, txmax=1000
0:0:1.0                              <--  seq=500, ack=0, len=500
0:0:1.0                              <--  seq=1000, ack=0, len=500
0:0:1.5     seq=0, ack=1000, len=0 -->
0:0:2.0                           ------  timeout=1+1, txmax=1500
0:0:2.0                              <--  seq=1500, ack=0, len=500
0:0:2.0                              <--  seq=2000, ack=0, len=500
0:0:2.0     seq=0, ack=1500, len=0 -->
0:0:2.5                           ------  timeout=1+1, txmax=2000
0:0:2.5                              <--  seq=2500, ack=0, len=500
0:0:2.5                              <--  seq=3000, ack=0, len=500
;ezen a ponton eljutottunk oda, hogy 2k kint van a halon ackolatnalul....
;innentol ez mar a rendes 2k-s window meretu mukodes....;))))))
0:0:2.5     seq=0, ack=2000, len=0 -->
0:0:3.0                           ------  timeout=1+1
0:0:3.0                              <--  seq=3500, ack=0, len=500
0:0:3.0     seq=0, ack=2500, len=0 -->
0:0:3.5                           ------  timeout=1+1
0:0:3.5                              <--  seq=4000, ack=0, len=500
---

---
te geped (ftp-clnt)             tavoli gep (ftp-srvr)
tcp.connect 4,3,2,1:21
              tcp.syn   --><--     tcp.syn+ack
              tcp.ack   -->
;innentol tcp.data reszre koncentralunk....;))))
                        <--     220 ftp ready.
           user jancsi  --><--  331 passwd?
           pass titkos  --><--  230 ok.
                type i  --><--  200 image
                mode s  --><--  200 stream
                stru f  --><--  200 file
                  pasv  --><--  227 passive (4,3,2,1,4,37)
tcp.connect 4.3.2.1:1061
   get ~/doku/notes.doc --><--     150 sending...
   [itt atmegy a file a masodik tcp kapcsolaton, le is bomlik, ha vege]
                        <--     226 succeed.
                  quit  --><--     221 cul8r
                        <--     tcp.fin
            tcp.fin+ack -->
---

na tovabbi jo kodolast mindenkinek.... 

Bocs ,de reagálnék saját magamra, nem írtam le mindent.

On Mon, 30 Apr 2001, HIX CODER wrote:

>Felado :  [Hungary]
>
>>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

Nem írtam, hogy persze a sorszámozásra szükség van, de leginkább azért,
hogy a fogadó oldalon az alkalmazás tudja, hogy veszett-e el csomag (nem
azért, hogy a vételi oldalnak ack-zzon a fogadó oldal).

Emellett írta valaki, hogy 400 byte kiírásától még nem szabad betelnie a
Windows belső buffereinek. Ez valóban így lehetm de csak linux alatt
vannak konkrét ismereteim: a send és recv függvényekben a kiírandó
adatmennyiséget size_t típusú változóban adhatjuk meg. Ennek maximális
értékét megmondja a sysconf(_SC_SSIZE_MAX), ami 32767. A belső buffereken
keresztül ekkora adat írását el kell tudni végezni, valószínűleg a
windowsban is hasonló értékek lehetnek.

Ja, és egyébként abban nem vagyok biztos, hogy a kollega által leírt trükk
nem működik, és hogy a az érveim korrektek, valaki léci még szóljon hozzá
a tehreadhez. Kíváncsi lennék, ha valaki kipróbálná a leírt dolgot.

Üdv!

--
tocsa

On Tue, Mar 24, 1964 at 07:14:58AM +0000,  wrote:
> 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)

Szerintem halal mindegy, hogy mire van most igeny, mire a srac
komolyan munkaba kerulne, mar tizszer megvaltozott minden trend.

> __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)

Mint ez az egesz rohadt informatika..

_tgz

ps kekec* legyszi allitsd takarekra magad, engem zavarsz

On Tue, Mar 24, 1964 at 01:24:50PM +0000,  wrote:
> Hogy miért ilyen lassú, annak sok oka lehet. Magasabb szintű: a windows
[...]
> Vagy alacsony szinten is lehetnek gondok: kiforratlan ethernet kártya
> driver, vagy maga az ethernet kártya (lásd NE2k).

Vagy maga az Ethernet protokoll. Sok kis csomag ==> sok eth frame
==> sokszor kell szot kerni a szegmensen es vegul sok lesz a
collision

> Milyen 100Mbites kártyád van?

Hat igen, vagy gyer a halokartya/kabel es hemzsegnek a broken
frame-ek.

> >HC> A socket MessageHandler-eben nem nagyon foglalkoztam az FD_WRITE
> >HC> 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.

Ezzel az a baj, hogy a TCP stack nem tud semmit a felette levo
alkalmazas igenyeirol. Hasznalhatod az stdio-t, ott te mondod
meg, hogy hogyan menjen a puffreles (es nem is kell ujrairni a
fel vilagot).

> 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,

Ez inkabb amiatt van, mert a flow control algoritmusok azt feltetelezik,
hogy a csomagvesztes halozati tulterheles miatt kovetkezett be,
nem pedig a kozeg hibajabol (ami feltetelezes egyre jobban megallja
a helyet kabelen, ahogy tobb lesz az uvegszal).

> >(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.

Nem voltam kepes vegigolvasni mc levelet (mar reg rajottem, hogy
reszemrol felesleges erofeszites megprobalni), de nekem is ez a
velemenyem, csak eppen mas okbol. Az FTP-nel biztosan nagy overheadet
okoz, hogy minden apro file-ra kulon connection-t kell letrehozni
es lebontani.

> 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.

TCP_NODELAY socket option

> Az UDP-nek csak akkor van értelme, ha nem baj, hogy ha esetleg elveszik a
> csomag,

Nalam a socket.h-ban definialva van egy SOCK_SEQPACKET
(sequenced, reliable, connection-based datagrams of fixed maximum
length) es egy SOCK_RDM (reliably-delivered messages) nevu socket
tipust; nem tudom, hogy az IP/TCP hierarchiaba hogyan fernek
bele, de talan jok valamire.

> 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.

No, habar en errol nem vagyok meggyozodve, de ha igy all a dolog,
akkor erdemes egy pillantast vetni az sched_setscheduler() es
tarsai fuggvenyekre, POSIX-ak mindannyian.

_tgz