Azért nem világos a dolog, mert a dinamikus IP címkiosztás nem pollingos rendszerű, hanem egy bekapcsolt gép a bekapcsolás folyamán kér IP címet.

Ez viszonylag bonyolult folyamat, de sok infó van róla a neten. Amit látok az megy egyértelműen broadcast ARP, mellyel az a folyamat játszódik le, hogy én tudom az IP címedet, te modjad meg nekem a hálókártyád fizikai (MAC) címét.
No ebből van tele a Chelló hálózat, legalábbi ilyen kérésekből, mert választ megfigyelésem alatt egyet sem láttam.

Ami még érdeke, hogy teljesen szabálytalan időközönként kérdezi a hálózatot, például a korábban említett 89.135.78.8 címet kb. 1 msec után, aztán 80 msec, stb. Az egyész hálózati forgalmat figyelve pedig látszólagos teljes káosz urlkodik ARP kérés területén.

Alapvetően szvsz. dinamikus az ip-d (Chello)a szolgáltató felől.Íígy nem is csoda hogy állandóan megkérdezi hogy lóg-e kártya v akármilyen bedugott eszköz a végén uo. mit amikor a belső hálót címzed.

Chelló hálózatba belenéztem Ethereal -al.
Csak érdeksség kedvéért: Router mogül netezek aztali géppel, és a routerem elé kötöttem egy HUB ot, ezt használom "T" elágazásnak, hogy a teljes hálózati forgalmat lássam a HUB szabad portján lévő laptomommal, amin fut az Ethereal.

Szóval amit nem értek: a hálózaton folyamatos ARP kérés érkezik innen IP: 89.135.79.254 (catv-59874ffe.catv.broadband.hu). Gyakorlatilag folyamatosan kérdezi a 89.135.x.x tartományt. Legalábbis amit én láttam belőle. Aztán nem szégyenl ismét ARP zni szinte egymás után ugyanazt a címet sem.
Például a 89.135.78.8 at ismételten kérdezte (Ethereal indítás 0.0000 sec) 0.000198 sec al, 0.001120 sec al, 0.088424 sec el, 4.025889 sec -el, és így tovább.
Válasz az ARP kérésre sehonnan nem érkezett.


Mi lenne a fenti rejtély magyarázata??? Látszólag teljesn feleslegesen szűkíti a sávszélességet.

Ki kellene próbálnom: full duplexben el kellene árasztanom a vevőt, és ethereallal megnézni hogyan alakul a TCP win ablaka, és a pause keretek a vonalon. Érdekelne melyik a meghatározó.
Mint irtad alacsonyabb szinten kevesebb erőforrást köt le, tehát azt kellene látnom, hogy a rendszer törekedik a Pause keretekkel való kompenzálásra. Próbált már valaki ilyesmit???

Nem - de ez csak elmélet - egyátalán nem mindegy, hogy milyen szinten van lekezelve egy probléma. Minél magasabb szinten, annál több erőforrást köt le, feleslegesen.

ez jogos, de akkor Ethernetben bekapcsolt folymatirányításra nincs is szükség, mert ott a TCP....
Márpedig rendszergazdák szorgalmasan állítgatják, bajlódnak vele, tehát feleslegesen teszik?

A többi kérdésre is van ötletetek?

persze, mivel más szinten van a kettő. TCP protokoll lehet pl. arcnet hálózaton, vagy RS232-n is. Ugyanígy fordítva, az ethernet felett sem kötelező a TCP/IP, lehet netbios vagy ipx/spx is.

Sziasztok!


Az eternet Full duplex módban való működésekor lehetőség van a forgalomszabályozás (Flow Control) bekapcsolására, Half duplex üzemmódban nincs.

Lehet kérdésem eléggé amatőr, de ezeken rágódom:

1. Milyért csak full duplex üzemmódban küldözgetünk a hálón forgalomszabályozó pause kereteket és Half Duplex esetén pedig nem???
Halfnál milyért nincs rá szükség, merthogy ott is megtelhet a fogadó bufferja, vagy hogyis állunk ezzel a dologgal?

2. Milyért van szükség egyáltalán a Flow Control (pause) keretekre, mikor ott van a TCP protokollban a csúszó ablakozás (window mező), ami ugye hasonló célt szolgál? Bizonyára van közöttük markáns különbség - ha már 2X megvan - de mi?

3. Továbbá néhány eszközön kikapcsolható ez a szolgáltatás (flow control). Ez mikor hasznos, és mikor érdemes be ill. kikapcsolni?
Az auto negotation mikor érdemes be ill. ki kapcsolni?

4. És meg egy kérdés, de ettől akár el is tekintenék: el tudnátok röviden, de érthetően magyarázni az Auto-Negotation működését?
(mi valójában az a Normal Link Pulse, Fast Link Pulse, hogyan van ezekbe bekódolva az eszköz saját képessége)
Már googliztam erről, de talán túl részletes volt volt a leírás, és sajna elvesztem a részletekben...