[Schwarzmueller]

Idézet: Renwick - Dátum: 2010. 07. 14. 10:50

Ja, és egyébként is a fél országnak a zárt osztályon lenne a helye ugyebár.
Amúgy meg továbbra sem értem, ha valakit zavarnak a hülyeségei, miért nem használja az ignore funkciót. Pont erre való.

üdv

R.

Hmm.. Azert a sünszaratás titeket anno zavart... Azert gondolom mindenki megkapta a magaet akkor.

Titeket lehet hogy tenyleg nem zavar, hogy egyesek miket muvelnek itt, de minket kurvara. Hm... Kettos merce rulez. Amugy meg az ignore gomb abban a pillanatban szart sem er, ha vki beidezi a tiltott faszkalapot.

Szarjatok sunt. (azert kivancsi vagyok, hogy ezert kibannoltok-e X idore)

[Eleanor]

Idézet: Schwarzmueller - Dátum: 2010. 07. 14. 13:08

Amugy meg az ignore gomb abban a pillanatban szart sem er, ha vki beidezi a tiltott faszkalapot.

Pedig "ignore" nélkül is lehetne, de hát ugye az olyan macerás.... há miért én, miért nem más?

[Carmaged]

Idézet: djculture - Dátum: 2010. 07. 14. 12:11

Megnéztem tegnap 20 helyröl is ha bevan az ember jelentkezve ez fogad:

Be vagyok jelentkezve a fórumra és megy a főoldal is. Utolsó fájerfokszot telepítem, amikor rinyál.

Egyébként sem láttam soha semmi olyan hibát, amiket itt írogattok. Lehet, hogy sok plugin/stb van fenn és az kavar be?

[Jahno]

Idézet: Renwick - Dátum: 2010. 07. 14. 10:50

Ja, és egyébként is a fél országnak a zárt osztályon lenne a helye ugyebár.
Amúgy meg továbbra sem értem, ha valakit zavarnak a hülyeségei, miért nem használja az ignore funkciót. Pont erre való.

Figy, tegyünk pontot a végére.

Most akkor tele lehet szarni a fórumot? Ha nem, akkor vágjuk ki az ilyen hülyéket, de most azonnal. Spambotot meg következő körben, mondjuk késő délután

Ha az ilyen kreténség/warez/spam megtűrt dolog, akkor viszont szólok ismerősöknek, hogy itt a dühöngő, szarják tele, jöhet a reklám, meg a spam.

Hümmm? Melyiket választod?

[Jahno]

Idézet: Schwarzmueller - Dátum: 2010. 07. 14. 13:08

Hmm.. Azert a sünszaratás titeket anno zavart... Azert gondolom mindenki megkapta a magaet akkor.

Akkor még meg, csak lementek a választások, most más a trend, ütemes metodológia ehhez képest kutyafüle lesz, mindjárt eldöntheti a két opciót, kap rá fél órát Utána szarunk és szaratunk, mert megfelelõ idõzítéssel kell birtokba venni az extenzív szinergiákat ugye

[debaj]

Idézet: Jahno - Dátum: 2010. 07. 14. 13:55

Figy, tegyünk pontot a végére.

Nem ártana, mert jól elbeszélgetünk itt magunkban, az üzemeltetének meg úgy tűnik, csak fellengzős beszólásra telik, érdemi válaszra már nem.

[Jahno]

10

[Jahno]

9

[djculture]

Idézet: Carmaged - Dátum: 2010. 07. 14. 13:38

Be vagyok jelentkezve a fórumra és megy a főoldal is. Utolsó fájerfokszot telepítem, amikor rinyál.

Egyébként sem láttam soha semmi olyan hibát, amiket itt írogattok. Lehet, hogy sok plugin/stb van fenn és az kavar be?

Egy darab külső plugint se használok a firefoxom meg 3.6.6 os

[Renwick]

Idézet: debaj - Dátum: 2010. 07. 14. 13:58

Nem ártana, mert jól elbeszélgetünk itt magunkban, az üzemeltetének meg úgy tűnik, csak fellengzős beszólásra telik, érdemi válaszra már nem.

Függetlenül attól, hogy a nyílt fenyegetés a szolgáltatás ellehetetlenítésével kapcsolatban eléggé érdekes, hovatovább vicces fordulat, talán lesz némi érdemi változás a témában, hamarosan lesz ugyanis valaki (egyelőre egy ember), aki több időt tud szánni a moderáció adminisztratív részére. Ettől még mindenki olyan baromságot ír a fórumba, amekkorára csak telik neki, mivel a hülyék szólásszabadságát sem lehet korlátozni.

üdv

R.

[debaj]

Idézet: Renwick - Dátum: 2010. 07. 14. 15:06

hamarosan lesz ugyanis valaki (egyelőre egy ember), aki több időt tud szánni a moderáció adminisztratív részére.

Na, már ez is valami.

(Azt már csak halkan jegyzem meg, hogy valahogy éreztem, hogy megint Jahno lesz a fasz.)

Szerkesztette: debaj 2010. 07. 14. 14:27 -kor

[Jahno]

Idézet: Renwick - Dátum: 2010. 07. 14. 15:06

Ettől még mindenki olyan baromságot ír a fórumba, amekkorára csak telik neki, mivel a hülyék szólásszabadságát sem lehet korlátozni.

Akkor bevállalom, hogy hülye vagyok. Esetleg minnyá csinálom is a nickem, bár az nem méltó hozzám.

[beta]

Idézet: Renwick - Dátum: 2010. 07. 14. 15:06

Ettől még mindenki olyan baromságot ír a fórumba, amekkorára csak telik neki, mivel a hülyék szólásszabadságát sem lehet korlátozni.

mutass legyszi egy szakmai forumot ahol nincsen moderacio!

[debaj]

Wow, didyman, kongretyuléjsün

[Renwick]

Idézet: beta - Dátum: 2010. 07. 14. 16:15

mutass legyszi egy szakmai forumot ahol nincsen moderacio!

"Szakmai" moderáció márpedig itt nem lesz.

üdv

R.

[debaj]

Idézet: Renwick - Dátum: 2010. 07. 14. 16:18

"Szakmai" moderáció márpedig itt nem lesz.

Nem is szakmaira vágytunk.

[Jahno]

Idézet: Renwick - Dátum: 2010. 07. 14. 16:18

"Szakmai" moderáció márpedig itt nem lesz.

Alakulhat.

Szóval zsidózás ugrik, többi baromság marad.

Most akkor a gyengébbek kedvéért mégegyszer leírom ugyanazt egy kicsit még az előzőeknél is szájbarágósabban, mert úgy látszik, hogy bárki akinek eddig ezt mondtam egyből megértette, csak nektek, diplomás számítástechnikusoknak van némi gondotok itt a szövegértelmezéssel: van egy darab pingidőnk az ICMP protokol által küldve, amelyet persze végül az ETHERNET protokol fog elküldeni, mint minden mást is. van egy darab byte-unk ami átmegy Tőlünk -> a routerunkon keresztül -> a szolgáltatónkon keresztül -> a célszerverig , amelyet ki pingeltünk a pingelés ténye végül az Ethernet protokollon keresztül fog megérkezni a routerünkön és a szolgáltatónkon keresztül a célszerverig amelyet kipingeltünk. A számítógépünkön fut az EDP kliens , Windows XP SP3-tól gyárilag aktív verziója és minden küldött ethernetcsomagot annak megfelelően késleltet MÁR AZ INDULÁS ELŐTTI PILLANATBAN, hogy ő mit szeretne mondani, és hát mi mást is szeretne mondani, mint azt hogy broadcastolja magát az EDP frame-en belül, választ keres az EDP csomagokra. Az szolgáltatónk számítógépén Windows XP SP3(vagy újabb) fut az EDP szerver , külön az EDP-re felkonfigurált verziója fut, amely minden EDP csomagot azonnal értelmez, válaszol és a kapott információt normál TCP/IP kapcsolaton továbbküldi máshova (központba, HQ-ra stb..) Huzamosabb kapcsolat épül ki A és B pont között a szolgáltatónkon keresztül (!) pörögnek a (TCP/IP, UDP stb.) csomagok, így tehát az ethernet csomagok is ... éppen lefele töltünk valami nagyobb file-t az X.X.X.X IP címről az 50xezredik csomag után már egy egész jó, várható időt lehet jósolni az addig lepörgött csomagok érkezési ideje szerint (remélem itt még nem vesztettétek el a fonalat !) ekkor lép közbe az EDP protokollunk, aki már persze eddig is nyilvántartotta az ethernet adatfolyamunkban két ethernet csomag érkezése közötti átlagosan eltelt időszakot (T delta), az X.X.X.X IP címről fogadott TCP layeren. (itt már bonyolódik a helyzet innentől csak két diplomásoknak ajánlom a figyelmet !) ekkor az EDP-nk ahelyett hogy a szokásos penzumban küldené a (válasz) csomagokat, ahelyett ~T delta/100 idővel szándékosan elkezd késleltetni , majd megint nem késik , majd megint késik , majd megint nem késik, amire a szolgáltatónk gépén futó EDP szerver "felfigyel", hiszen ő is méri minden kliense alsóbb szintjén történő adatfolyamaiban végbemenő átlagos ethernet csomagközti időket. Fontos megjegyezni, hogy az EDP protokoll semmilyen változást nem eszközöl a felsőbbszintű adatfolyamokban , tehát az ethernet rétegben egy bit nem sok , de annyi változás sem lesz. A másik amit meg kell érteni, hogy míg a gépünk valójában egy másik internetre kötött géppel kommunikál , A SZOLGÁLTATÓNKON KERESZTÜL, addig az EDP protokollunk a gépünkben , a szolgáltató gépével kommunikál a késedelmi időközökkel illetve azok hiányával. A szolgáltatónk is nagyon jól tudja, hogy A-ból B-be rajta keresztül mennyi idő alatt jut el egy csomag, ezért a csomagok normális érkezési idejére rá tud számolni egy kis késedelmi időt akár mindkét irányba egyszerre is. Ez tehát egy szteganográfiai módszer: adat-az-adatfolyamban 0 : az eredeti 0-ás bit 1 : az eredeti 1-es bit - : a normál időköz = : a késleltetett időköz 01001000-10010010-01101011-1101010-0100100=10010111 01001001=00010000-00010010-1000010=0010111-10000010 01001000-10010010-01101011-1101010-0100100=10010111 01001001-00010000=00010010-1000010=0010111-10000010 01001000-10010010-01101011-1101010-0100100=10010111 01001001=00010000-00010010-1000010=0010111-10000010 01001000-10010010=01101011-1101010-0100100=10010111 01001001=00010000=00010010-1000010=0010111-10000010 így tehát csak a -, és = jeleket összerakva tulajdonképpen egy rendes bináris adatfolyamot kapunk: -=--=-==-=-=--====-==---=-=--==-=--=-=-=-=--= "
Most akkor a gyengébbek kedvéért mégegyszer leírom ugyanazt egy kicsit még az előzőeknél is szájbarágósabban, mert úgy látszik, hogy bárki akinek eddig ezt mondtam egyből megértette, csak nektek, diplomás számítástechnikusoknak van némi gondotok itt a szövegértelmezéssel: van egy darab pingidőnk az ICMP protokol által küldve, amelyet persze végül az ETHERNET protokol fog elküldeni, mint minden mást is. van egy darab byte-unk ami átmegy Tőlünk -> a routerunkon keresztül -> a szolgáltatónkon keresztül -> a célszerverig , amelyet ki pingeltünk a pingelés ténye végül az Ethernet protokollon keresztül fog megérkezni a routerünkön és a szolgáltatónkon keresztül a célszerverig amelyet kipingeltünk. A számítógépünkön fut az EDP kliens , Windows XP SP3-tól gyárilag aktív verziója és minden küldött ethernetcsomagot annak megfelelően késleltet MÁR AZ INDULÁS ELŐTTI PILLANATBAN, hogy ő mit szeretne mondani, és hát mi mást is szeretne mondani, mint azt hogy broadcastolja magát az EDP frame-en belül, választ keres az EDP csomagokra. Az szolgáltatónk számítógépén Windows XP SP3(vagy újabb) fut az EDP szerver , külön az EDP-re felkonfigurált verziója fut, amely minden EDP csomagot azonnal értelmez, válaszol és a kapott információt normál TCP/IP kapcsolaton továbbküldi máshova (központba, HQ-ra stb..) Huzamosabb kapcsolat épül ki A és B pont között a szolgáltatónkon keresztül (!) pörögnek a (TCP/IP, UDP stb.) csomagok, így tehát az ethernet csomagok is ... éppen lefele töltünk valami nagyobb file-t az X.X.X.X IP címről az 50xezredik csomag után már egy egész jó, várható időt lehet jósolni az addig lepörgött csomagok érkezési ideje szerint (remélem itt még nem vesztettétek el a fonalat !) ekkor lép közbe az EDP protokollunk, aki már persze eddig is nyilvántartotta az ethernet adatfolyamunkban két ethernet csomag érkezése közötti átlagosan eltelt időszakot (T delta), az X.X.X.X IP címről fogadott TCP layeren. (itt már bonyolódik a helyzet innentől csak két diplomásoknak ajánlom a figyelmet !) ekkor az EDP-nk ahelyett hogy a szokásos penzumban küldené a (válasz) csomagokat, ahelyett ~T delta/100 idővel szándékosan elkezd késleltetni , majd megint nem késik , majd megint késik , majd megint nem késik, amire a szolgáltatónk gépén futó EDP szerver "felfigyel", hiszen ő is méri minden kliense alsóbb szintjén történő adatfolyamaiban végbemenő átlagos ethernet csomagközti időket. Fontos megjegyezni, hogy az EDP protokoll semmilyen változást nem eszközöl a felsőbbszintű adatfolyamokban , tehát az ethernet rétegben egy bit nem sok , de annyi változás sem lesz. A másik amit meg kell érteni, hogy míg a gépünk valójában egy másik internetre kötött géppel kommunikál , A SZOLGÁLTATÓNKON KERESZTÜL, addig az EDP protokollunk a gépünkben , a szolgáltató gépével kommunikál a késedelmi időközökkel illetve azok hiányával. A szolgáltatónk is nagyon jól tudja, hogy A-ból B-be rajta keresztül mennyi idő alatt jut el egy csomag, ezért a csomagok normális érkezési idejére rá tud számolni egy kis késedelmi időt akár mindkét irányba egyszerre is. Ez tehát egy szteganográfiai módszer: adat-az-adatfolyamban 0 : az eredeti 0-ás bit 1 : az eredeti 1-es bit - : a normál időköz = : a késleltetett időköz 01001000-10010010-01101011-1101010-0100100=10010111 01001001=00010000-00010010-1000010=0010111-10000010 01001000-10010010-01101011-1101010-0100100=10010111 01001001-00010000=00010010-1000010=0010111-10000010 01001000-10010010-01101011-1101010-0100100=10010111 01001001=00010000-00010010-1000010=0010111-10000010 01001000-10010010=01101011-1101010-0100100=10010111 01001001=00010000=00010010-1000010=0010111-10000010 így tehát csak a -, és = jeleket összerakva tulajdonképpen egy rendes bináris adatfolyamot kapunk: -=--=-==-=-=--====-==---=-=--==-=--=-=-=-=--= "
Most akkor a gyengébbek kedvéért mégegyszer leírom ugyanazt egy kicsit még az előzőeknél is szájbarágósabban, mert úgy látszik, hogy bárki akinek eddig ezt mondtam egyből megértette, csak nektek, diplomás számítástechnikusoknak van némi gondotok itt a szövegértelmezéssel: van egy darab pingidőnk az ICMP protokol által küldve, amelyet persze végül az ETHERNET protokol fog elküldeni, mint minden mást is. van egy darab byte-unk ami átmegy Tőlünk -> a routerunkon keresztül -> a szolgáltatónkon keresztül -> a célszerverig , amelyet ki pingeltünk a pingelés ténye végül az Ethernet protokollon keresztül fog megérkezni a routerünkön és a szolgáltatónkon keresztül a célszerverig amelyet kipingeltünk. A számítógépünkön fut az EDP kliens , Windows XP SP3-tól gyárilag aktív verziója és minden küldött ethernetcsomagot annak megfelelően késleltet MÁR AZ INDULÁS ELŐTTI PILLANATBAN, hogy ő mit szeretne mondani, és hát mi mást is szeretne mondani, mint azt hogy broadcastolja magát az EDP frame-en belül, választ keres az EDP csomagokra. Az szolgáltatónk számítógépén Windows XP SP3(vagy újabb) fut az EDP szerver , külön az EDP-re felkonfigurált verziója fut, amely minden EDP csomagot azonnal értelmez, válaszol és a kapott információt normál TCP/IP kapcsolaton továbbküldi máshova (központba, HQ-ra stb..) Huzamosabb kapcsolat épül ki A és B pont között a szolgáltatónkon keresztül (!) pörögnek a (TCP/IP, UDP stb.) csomagok, így tehát az ethernet csomagok is ... éppen lefele töltünk valami nagyobb file-t az X.X.X.X IP címről az 50xezredik csomag után már egy egész jó, várható időt lehet jósolni az addig lepörgött csomagok érkezési ideje szerint (remélem itt még nem vesztettétek el a fonalat !) ekkor lép közbe az EDP protokollunk, aki már persze eddig is nyilvántartotta az ethernet adatfolyamunkban két ethernet csomag érkezése közötti átlagosan eltelt időszakot (T delta), az X.X.X.X IP címről fogadott TCP layeren. (itt már bonyolódik a helyzet innentől csak két diplomásoknak ajánlom a figyelmet !) ekkor az EDP-nk ahelyett hogy a szokásos penzumban küldené a (válasz) csomagokat, ahelyett ~T delta/100 idővel szándékosan elkezd késleltetni , majd megint nem késik , majd megint késik , majd megint nem késik, amire a szolgáltatónk gépén futó EDP szerver "felfigyel", hiszen ő is méri minden kliense alsóbb szintjén történő adatfolyamaiban végbemenő átlagos ethernet csomagközti időket. Fontos megjegyezni, hogy az EDP protokoll semmilyen változást nem eszközöl a felsőbbszintű adatfolyamokban , tehát az ethernet rétegben egy bit nem sok , de annyi változás sem lesz. A másik amit meg kell érteni, hogy míg a gépünk valójában egy másik internetre kötött géppel kommunikál , A SZOLGÁLTATÓNKON KERESZTÜL, addig az EDP protokollunk a gépünkben , a szolgáltató gépével kommunikál a késedelmi időközökkel illetve azok hiányával. A szolgáltatónk is nagyon jól tudja, hogy A-ból B-be rajta keresztül mennyi idő alatt jut el egy csomag, ezért a csomagok normális érkezési idejére rá tud számolni egy kis késedelmi időt akár mindkét irányba egyszerre is. Ez tehát egy szteganográfiai módszer: adat-az-adatfolyamban 0 : az eredeti 0-ás bit 1 : az eredeti 1-es bit - : a normál időköz = : a késleltetett időköz 01001000-10010010-01101011-1101010-0100100=10010111 01001001=00010000-00010010-1000010=0010111-10000010 01001000-10010010-01101011-1101010-0100100=10010111 01001001-00010000=00010010-1000010=0010111-10000010 01001000-10010010-01101011-1101010-0100100=10010111 01001001=00010000-00010010-1000010=0010111-10000010 01001000-10010010=01101011-1101010-0100100=10010111 01001001=00010000=00010010-1000010=0010111-10000010 így tehát csak a -, és = jeleket összerakva tulajdonképpen egy rendes bináris adatfolyamot kapunk: -=--=-==-=-=--====-==---=-=--==-=--=-=-=-=--= "

[SityiSXT]

Jahno, akadnak még ott gyögyszemek, nem kell 3x ugyanazt beidézni:

Az mit tesz, hogy "szarrá titkosítva"?

Mindössze annyit, hogy nagyon alaposan el van titkosítva. Byte-onként persze nem bitenként.



A "kernelmemória" hogyan kapcsolódik a TCP stack-hez?

A kernelen keresztül.





Honnan tudod, hogy mi van a "kernel-memóriában"?

Onnan nem vagyok hülyegyerek.





Hogyan is lehetne BÁRMILYEN oprendszer legbelső működési alapelve egy "protokoll" védelme?

Pontosan úgy, ahogy az alábbi az ábra mutatja.

Annyit még, hogy eddig az "EDP"-t hálózati kommunikáció ügyén "veséztük". Szóba sem került más kommunikációs forma. Akkor nem értem, hogy hogy van az, hogy az egész vista, 7 ezekre épül?

Már az XP SP2-be is megpróbálták beletenni, béta verzióban, de túlságosan egybe volt nőve a Windows aktívációval , és az egyéb titkosítást végző és belső sunnyogásokat vezérlő rendszerekkel (SAM stb.) s mikor a ruszki hekkerek kiherélték és publikálták a megtört XP SP2-t
abból már hiányzott a kívülről , harmadik félnek feltüntetett szoftverek által utólag aktíválni hivatott trójai EDP rendszer.
Ezután a Viszta már alapjaiban gondoskodik az EDP kapcsolatokról , teljesen elszeparálva a többi folyamattól. A kezdeti borzalmas gépigényét is ez okozta. A Win7-re már újraírhatták az egészet mégegyszer mert már legalább nem fogja le annyira az egész gépet, mint a Vista tette.


Az ISP honnan a bánatból tudja, hogy azon az egy vezetéken az egyetlen nyilvános IP-ről épp melyik gép adatcsomagjának a késleltetését figyeli? 4 totál eltérő gépről van szó, tehát fullheterogén a hálózat! Azt meg csak a router tudja, hogy a beérkező csomagok közül melyik kinek megy...


Jogos a kérdés, és valószínűleg a NAT mögött álló számítógéphálózatok jelentik a legnagyobb problémát az EDP szervereknek. Ebben az esetben a dolog úgy működik, hogy az EDP szerver sokáig hallgatja az EDP broadcast-okat , amelyek a NAT mögött álló gépektől érkeznek. A NAT mögött álló gép viszont az EDP broadcastba belefűzi a saját helyi hálózati IP címét. Miután az EDP szerver feltérképezettnek látja a NAT mögött álló gépeket, a TCP stream-enként jól elkülöníthető  a NAT mögött álló gépek egyes TCP csomagjait aszerint késlelteti, hogy melyiknek milyen választ kell adnia, így sorba végigmegy az összes EDP kliens gépen. Értelemszerűen egy körben csak egy géppel veheti fel az EDP kapcsolatot, ilyenkor az összes többi EDP kliens CRC hibákat fog tapasztalni az EDP csatornában. Mindazonáltal azt is hozzá kell tenni, hogy az EDP szervereknek majdhogynem elég volna  read-only EDP módban működniük, hiszen a globális cionista szektáknak nincs szüksége az EDP által téged vezérelni, elég nekik a NAT mögött álló IP-d és a puszta tény, hogy Windows-t használsz (Vista, 7 , XP-SP3) ezután már hagyományos módszerekkel is be tudnak jutni, nem kell az irdatlanul lassú , (de BIZTOS !) EDP-vel szívniuk.
Ha leesett volna hogy az adat-az-adatfolyamban egy PLUSZ információ, ahol az eredeti adat egy bitet sem változik, mégis az időegységnyi csúsztatásokkal IGENIS megkapja az ISP EDP szervere a NAT mögött álló összes EDP-kliens belső , alhálózati IP címét, az EDP protokolltól !


Szép sorban először az egyik géppel, majd a másikkal, majd a harmadikkal, TCP folyamonként (Follow TCP stream) csinál egy kézfogást, ilyenkor a többi EDP kliens gép , a NAT mögött , csak figyel, broadcastol, és persze a saját EDP-jük CRC hibákat kap, viszont az első gép, amelyikkel az ISP EDP szervere felvette a kapcsolatot, (az EDP-n keresztül, hiszen a routered előtt már eleve csúszni fog annyit az egész ethernet csomag, amennyit kell)


Jól van látom már megint az oviba kell kezdeni, nézzünk egy példát:

szépen pörögnek a csomagjaid kifele, be van kapcsolva mind a 4 géped a routerek mögött..

az ISP EDP szervere szépen látja hogy milyen TCP stream-ek mennek a külső IP-címed felé:

- a nagyfaterod nézi a kuruc.info-t

- a szomszédod nézi a heti-hetes.hu-t

- az asszonyod valami online flessbepasziánszt nyom,

-  te meg éppen töltöd le a Shrek4 trailer-ét a.

az ISP-d szépen tudja követni az egyes TCP-streameket, tudja, hogy a NAT mögött feltehetően 4 számítógép van, elkönyveli. Az egyes kifelejövő válaszcsomagok késleltetési idejéből, már azt is tudja, hogy a 4ből hány gép tartalmaz EDP klienst. Így rájön, hogy az egyik gép a 4-ből az nem tartalmaz EDP klienst (feltehetően valami Linux disztribúció)
Ekkor megkeresi azt a TCP-stream-et ahol a legjobban pörögnek a csomagok (Shrek4 trailer, a te géped) a 300adik csomag után, kap egy átlag 13000 mikroszekundum per csomag mindkét EDP-vel felszerelet gép. A tied is és az ISP EDP szervere is.
Ekkor a te géped is, és az ISP gépe is , elkezdi szándékosan csúsztatni a csomagokat 13130 mikroszekundumra (130 = 13000/100) 130 mikroszekundummal, amennyiben 1-es bitet akar kifejezni, 260 mikroszekundummal pedig, ha 0-sat , néhányszáz ethernetcsomag megérkezése után már létre is jött az EDP kapcsolat a géped és az ISP gépe között az EDP csatornán , anélkül hogy a leghalványabb fogalmad lett volna róla, te csak a Shrek 4 trailerét töltötted közbe le. Eközben az ISP-d EDP szervere megtudta és továbbküldte az admin jelszavadat, a belső alhálózati IP címedet , autokalibrációt végzett az átlagosan pörögő csomagjaidról és a szükséges késleltetési időket is kiszámolta a géped irányába.

Szerkesztette: SityiSXT 2010. 07. 14. 15:45 -kor

[beta]

[url="http://www.youtube.com/watch?v=N_bUL4ljKHk"]http://www.youtube.c...h?v=N_bUL4ljKHk[/url]

[Jahno]

Idézet: SityiSXT - Dátum: 2010. 07. 14. 16:41

Jahno, akadnak még ott gyögyszemek, nem kell 3x ugyanazt beidézni:

Nekem pont fordított a meglátásom: jövök én, teljes nyugalommal, hogy nyissak egy topikot, amely idevág a témába, bele neki , in medias rest. Számtek fórum, hw- és állítólag sw is, meg minden..
Leírom, linkelek, bizonyítok, erre jön pár gyászhuszár, akinek mintha olyan volna ez a topik , mint ördögnek a tömjénfüst, nekik mindennél fontosabb hogy Gizike, egyszerű kódot adjon meg, mert
akkor nekik könnyű dolguk lesz majd feltörni, de Gizike mától ezt a topikot fogja olvasni, sőt még a kollégáinak is ki fogja majdan nyomtatni tanulságképpen, bármennyire is fáj, ez az itt jelenlévőknek.

Pedig nagyon olyan szaga van a mondanivalójuknak, hogy "Gizi-gizi látod, hogy mind1 mekkora jelszót acc meg, így-is úgy-is feltöri a Náza és a cionista bratyijaink" én pedig pont most bizonyítottam be, hogy nem mind1 mekkora kódot ad meg Gizella, és hogy így lehet, de úgy viszont SOHA nem fogják megtörni.