Szöveg tömörítés

Szöveg tömörítés
2006-04-12T08:51:16+02:00
2006-04-18T09:25:14+02:00
2022-10-31T07:30:37+01:00
  • Hi!

    Vagy nem. A Nagle-algoritmustól függően.

    Oks, én arra gondolok amikor egy lezárt blokkot küldesz el, és az tényleg elmegy egy fizikai csomagban (bár a TCP/IP-nek ilyen mélységig nem gondoltam/néztem utánna).
    Mutasd a teljes hozzászólást!
  • Passz , qos-t , netbiost nem nyiffantom ki anélkül hogy tudnám tényleg mihez kellenek.
    Mutasd a teljes hozzászólást!
  • Épp egy linux előtt ülök, ott (tudtommal) nincs semmilyen "felesleges" forgalom.

    Win-nél is (gondolom) csak akkor van ilyen, amikor a win ki próbálja találni hogy épül fel a hálózat, meg amikor QoS csomagokat küld, hogy sávszélességet próbáljon magának foglalni.

    Szóval ha ezek ("windows hálózat" vagy mi, QoS, meg esetleg a netbios) nincsenek beikszelve a kapcsolatnál, akkor nem kéne "zaj"-nak lennie.

    Szerintem.

    Ha van egy "rendes" tűzfal a gépen amivel le lehet tiltani minden hálózati forgalmat az 56bájtok küldözgetésének a kivételével, akkor le lehetne választani a kimenő "zaj"-t a tényleges adatforgalomról.
    Mutasd a teljes hozzászólást!
  • Pont akartam írni:
    Egy újrabootolt gépen , ha fellépsz a netre , és nézed a forgalomszámlálót, 10 perc múlva 0 byte-ot mutat nálad?
    Mutasd a teljes hozzászólást!
  • Pár napja felraktam egy net monitort,


    Még sose láttam. Én a helyedben utánaolvasnék, és elkezdenék nyomozni, hogy mi történik a dróton:

    http://www.netacademia.net/tudastar/articlepage.aspx?upid=228
    Mutasd a teljes hozzászólást!
  • Pár napja felraktam egy net monitort,
    nem futott semmi a gépen,de a forgalom számláló mégis mocorgott, ezért használom a "menő" 'hálózati zaj' kifejezést
    Mutasd a teljes hozzászólást!
  • Egy response.write van , 56byte már csak nem darabolódik fel a http protokoll miatt,


    Az számít(hat), hogy a socket-be hány írásművelettel kerül be az 56bájt. Csak akkor látok esélyt rá hogy az OS sok kicsi csomagot küldjön ki (sok fejléccel felduzzasztva a forgalmat), ha több írásművelettel íródik ki az 56bájt a socket-be.

    ez a 8K - 10 perc alatt már tiszta hálózati zaj lesz. (keep-alive, stb)


    Rossz hírem van, a keep-alive csak pár órával azután lép életbe, hogy teljesen megszünt a forgalom a kapcsolaton. Ha fél percenként van forgalom a két pont között, akkor biztos hogy nincs keep-alive tesztelés.

    Egyébként jól hangzik ez a "hálózati zaj" csak nincs értelme.

    Szerintem két dolgot tehetsz. Az egyik az, hogy hagyod az egészet ahogy van, a másik meg az, hogy elkezded kinyomozni, hogy miből adódik az adatforgalom túlzott nagysága.
    Mutasd a teljes hozzászólást!
  • Egy response.write van , 56byte már csak nem darabolódik fel a http protokoll miatt, ez a 8K - 10 perc alatt már tiszta hálózati zaj lesz. (keep-alive, stb)
    Mutasd a teljes hozzászólást!
  • Úgy írod ki a küldendő adatokat a socket-be, hogy előbb egy pufferbe összegyüjtöd őket és a puffert egy művelettel írod ki?

    Vagy több egymást követő írásművelettel?
    Mutasd a teljes hozzászólást!
  • Az ismétlődő lekérésekben felutazott
    egy request header ,és visszajött egy response header is.
    Átírtam a klienst http streaming-esre (ez már gyakorlatilag eléri egy socket megoldás színvonalát)
    , amire a 10 perces forgalom visszaesett 12,9K-ra

    3K connectálásnál keletkezik ezt észrevettem , tehát a régi megoldásnál
    20-3=17K volt
    most
    12,9-3=9,9K lett
    Mutasd a teljes hozzászólást!
  • A szerver oldalon meg van kötve a kezem: IIS/ASP.NET
    Mutasd a teljes hozzászólást!
  • UDP-t használj ne TCP-t. Ha választ is vársz, akkor használj egy bájtot csomagazonosítóként.
    Megyek inni. Bye
    Mutasd a teljes hozzászólást!
  • Egyben "flush"-olja az 56 byte-ot.


    Gondolkodjunk: tény hogy "sok" adat mozog, miközben "kevés"-nek kéne mozognia.

    Következésképp két eset lehetséges:

    A: amit "kevés"-nek képzelünk, az valójában "sok".

    B: amit "sok"-nak mértünk, az valójában "kevés", mert olyasmi is bele lett számolva/mérve, ami nem oda tartozik.

    C: kihagytam valamit?
    Mutasd a teljes hozzászólást!
  • Egyben "flush"-olja az 56 byte-ot.
    Mutasd a teljes hozzászólást!
  • Igen , egy "keep-alive" kommunikáció gyanús hogy tényleg lehet.
    Mutasd a teljes hozzászólást!
  • Ha küldesz egy üzenetet, szépen kódolva, az bizony elsprintel egy adatcsomagban.


    Vagy nem. A Nagle-algoritmustól függően.

    Nagle's algorithm - Wikipedia, the free encyclopedia

    "
    [...] the 'small packet problem', where an application repeatedly emits data in small chunks, frequently only 1 byte in size. Since TCP packets have a 40 byte header, this results in a 41 byte packet for 1 byte of useful information, a huge overhead.
    "

    Mintha ebben az esetben is valami ilyesmi történne.
    Mutasd a teljes hozzászólást!
  • Hi!

    Szóval lehet hogy túl sok idő telik el az egyes 4bájtos(?) kiírások között, és az OS emiatt egy-egy csomagot csinál belőlük, ahelyett hogy összevárná őket egy küldendő csomagba.

    Hát, lehet, hogy Ő(konzul) csinálja, mert az OS-nak nem szokása ilyent csinálni. Ha küldesz egy üzenetet, szépen kódolva, az bizony elsprintel 1 adatcsomagban.
    Mutasd a teljes hozzászólást!
  • Hi!

    6byte*2*10 (10 perc alatt) az 1K körül van , a forgalom 20K lett.

    Az 56 bajtot is 1K-as blokkban kuldi el?

    Megaztan megy ott mas csomag is (pl koszi eztete vettem, koszi itt a lista ezek jottek at, koszi megkaptam, elsz meg, helo, ect.)
    Mutasd a teljes hozzászólást!
  • 56byte*2*10 (10 perc alatt) az 1K körül van , a forgalom 20K lett.


    Számolgassunk: ha 4 bájtos egy üzenet, és ha üzenetenként 60 bájt a TCP+IP fejléc, akkor az annyi mint

    (4+60 bájt/üzenet)* (14*2 üzenet/perc) * (10 perc) = 17 920 bájt

    Szóval lehet hogy túl sok idő telik el az egyes 4bájtos(?) kiírások között, és az OS emiatt egy-egy csomagot csinál belőlük, ahelyett hogy összevárná őket egy küldendő csomagba.
    Mutasd a teljes hozzászólást!
  • Hi!

    , ééérted ugye?

    iiiiiiggeeeeennnn

    de ha egy csomag 256 byte,

    Akkor csinalni kell olyan oldalkat, amiben 1 bajtos adatok vannak, es abbol jol meggazdagodni, nemde
    Mutasd a teljes hozzászólást!
  • Ez még mindig sok.
    56byte*2*10 (10 perc alatt) az 1K körül van , a forgalom 20K lett.
    Még ha minden lekérésnél volt +64 byte header , még annak is csak mondjuk 3Knak kellett volna lennie
    Mutasd a teljes hozzászólást!
  • a keletkezett forgalom 95%-a valamilyen "zaj".


    Inkább kísérő infó, úgymint a címzett és feladó IP címe és portszáma, csomagméret, csomagsorszám, stb.:

    The TCP/IP Guide - IP Datagram General Format
    The TCP/IP Guide - TCP Message (Segment) Format
    Mutasd a teljes hozzászólást!
  • Egyenlőre nem nagyon jött be a dolog.
    10 perc alatt 20K forgalom keletkezett úgy hogy nem ment csak a lekérdező program. (30mp-ként 56 byte ment át).
    Ebből az jön le , hogy a keletkezett forgalom 95%-a valamilyen "zaj".
    Mutasd a teljes hozzászólást!
  • Tényleg db bájtok után kell fizetni , de ha egy csomag 256 byte,
    és 100 byte-os batyuban mennek át az adatok (de egy 256 byte-os csomagban)
    akkor mindegy , ééérted ugye?
    Mutasd a teljes hozzászólást!
  • Hi!

    pl 256 , akkor felesleges tovább bűvészkednem.

    Nagyobb
    Bűvészkedj tovább, mert mobiltelefonon az adatcsomag db bajtok után kell fizetni (persze beferhet az atlagba).
    Mutasd a teljes hozzászólást!
  • Azt nem tudom egy tcp csomag hány byte mert ha pl 256 , akkor felesleges tovább bűvészkednem.
    Mutasd a teljes hozzászólást!
  • Kommersz GRPS internetről van szó ,
    semmi AT és hasonlók.
    Mutasd a teljes hozzászólást!
  • Hi!

    ... nem nagyon reagaltal XiX 2006.4.12. 15:43-as hozzaszolasahoz. ... Sztem eleg jo megoldas a XiX-e. ... Valszeg ez nem lesz jo...tul kicsi a hatasfoka...

    Amúgy nem vártam rá választ.
    Köszönöm a segítségedet
    Mutasd a teljes hozzászólást!
  • Hi!

    Biteket szamolj, ne byte-at bár a gyorsaság oltárán feláldozható a méret? Mert a jelenlegi gyors.
    Ne nézzük :: 32bit ebből 24 bit a számnak.
    A szám :: -+65536.XY, szorozd fel 100-al, egesz szam lesz. Max 6553699 = log2 = 22,643 23bit és a előjel 1 bit hát ez nem jött össze.
    Nézzük a huffmant
    A statikust hasznájuk, egyszer átküldjük a táblát.
    4 bájt min 200-as max 500-as csomagban, foglalkozzunk a minimálissal.
    200/4=50 darab,
    1) ha a statuszokból az eloszlás jó, lehet huffmant használni (ha 1 db statusz legalább 12 darab felett van)
    2) ha a mezőnevekből néhány többször szerepel, akor is lehet huff (ekkor több táblát használhatsz, a gyakoriságoknak megfelelően) de a hatásfok nagyon kicsi lesz
    3) a számoknál (esetleg) a különbségek átküldése, azaz sorba van rakva és ha a számok n2-n1 különbsége kisebb mint a számok eredeti mérete akkor a különbségkódolás használható.

    Az 1) pontban lehetségese, hiszen a státusz 50 elemnél átagosan 6 (50/8). Ha ennél több (vagy sokkal több) szerepel a huff egy tud tömöríteni.
    A 2) pontban az 1)-hez hasonlóan lehet eljárni, bár a mezőnév valszeg így nem tömöríthető.
    A 3) pont, jelenleg gőzöm sincs róla
    Ezeket lehet 3 különálló tömbe szervezni és úgy feldolgozni.
    Mutasd a teljes hozzászólást!
  • 4*20 + 29 bájt a keret (asszem). De nézd meg. Telepítsd fel a GSM modulodat (telefon, ipari) standard modemként. Állítsd be a modem inicializálós stringjének az alábbi AT parancsot:
    AT+CGDCONT=1,"IP","APN"
    (Az APN szöveg helyére a szolgáltatód által megadottat írd!)
    Majd kpacsolódj a GPRS hálóhoz a *99***1# hívószámmal. A kapcsolat felépülése után küldj csomagokat és figyeld az status ablakban a küldött és fogadott bájtok számát.

    Szvsz, 80 bájt esetén nem érdemes tömörítgetni: kevés a nyereség és annak egy részét úgy is felemészti vmilyen leíró/jelző bit/bájt struktúra.

    Ha mégis, akkor csinálhatsz vmilyen statisztikai elven alapulót: megszámolod, hogy az egyes bájtokból hány darab van, majd a leggyakoribb bájtot tárolod a legkevesebb biten. Kapsz egy bitfolyamot. Elvégre legrosszabb esetben max. 80 különböző bájtod lehet.
    Vagy bájtsorozatok ismétlődését keresed és jelzőbájt + darab + offset segítségével nyerhetsz bájtokat.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd