Hírek | Archívum | Fórum | IRC | Amiga | AmigaOS | FAQ | RSS

 - Fórumok - Keresés - Statisztika - Szabályzat - Pegasos.hu fórum
forum.amigaspirit.hu / Classic AmigaOS / AmiTCP vs. Miami
<< . 1 . 2 . 3 . 4 . >>
Szerző Üzenet
AliveMOon
Tag

# Elküldve: 2012. Dec. 14. 13:42 - Szerkesztve: alivemoon


Quoting: charlie
1., a TCP socket receive és send buffer méretét a TCP packet headerben egy 16 bites érték írja le, emiatt az socket buffer mérete alapból nem lehet nagyobb 64k-nál. Ez azt jelenti, hogy egyszerre nem lehet "úton" több adat a két szerver között, hiszen amíg a túloldalról az ACK packetek meg nem jöttek, addig az adat hiába lett elküldve, benne marad a helyi bufferben.


Ehhez meg azt írtam, hogy én a csomagjaim elejében átküldöm a kívánt teljes adataim méretét és mivel saját programjaimmal kommunikálok, értik, hogy most sok fog jönni, ezért a fogadó oldal is megnöveli a buffert.
Ezért szinkronban növekednek és csökkennek a bufferek.

Chain-Q
Divatamigás

# Elküldve: 2012. Dec. 14. 14:10 - Szerkesztve: charlie


@AliveMOon:

Ez pedig a rossz megoldás. Egyrészt teljesen hülyeség menet közben változtatni a socket buffer méretét, a már említett TCP Window Scaling miatt, ami úgyis felülír mindent, ideális esetben... Ha meg nem, akkor csak a saját lehetséges sávszélességedet vágod le, mert feljebb úgysem fog menni, mintha az elején beállítanád maximumra, aztán úgy hagynád. A többi socketnek sem segít, lévén a TCP receive és send buffer mérete per socket értendő.

Másrészt pedig ha az az igény, hogy ne várja meg az alkalmazás, amíg egy teljes packetnyi méretű adat a bufferbe kerül (értsd: sok kicsi packetet küldesz), akkor a TCP_NODELAY opciót kell használni a socketre. Ez szépen működik együtt a nagy buffermérettel is. Ekkor a socketre került adatok azonnal küldésre kerülnek, nem történik várakozás kis packeteknél sem.

Összességében, az általad javasolt megoldás szerintem semmit sem segít, felesleges bonyolítás, ráadásul tipikus példája az API abuse-nak. Egy olyan programozó koncepciója, aki sokkal okosabbnak hiszi magát annál aki a TCP/IP stacket írta és a TCP protokollt tervezte. Ritkán működik az ilyesmi.

Szerk:
És mégegyszer *UTOLJÁRA* leírom, hátha nem ment át: az általam leírt problémában kurvára mindegy, hogy mekkorára állítod a TCP buffer értékét. Egy bizonyos sávszélesség igény fölött ugyanis több százszor kell select()-elni másodpercenként, ami fizikailag lehetetlen, ha a select() minimális timeoutja 1/50-ed másodperc.

Pl. ha a maximális 64k-s buffered van, és mondjuk minden 20ms-t váró select() után tényleg ki is tudsz írni 64k-t akkor a maximális ELMÉLETI sávszélességed 3.2MB/sec (azaz 64k * 50), ami Amigán soknak tűnik, de egy modern hálózaton igazából semmire sem elég, ráadásul általában sokkal kisebb méretű packetekkel dobálózol mint 64k, ami ennek megfelelően le is csökkenti a lehetséges sávszélességet (pl. ha MTU méretű packeteket küldesz, ami 1500 byte, akkor már csak 1.5K * 50 a max, ami 75K/sec). Általános iskolai matematika, csak szólok, de még nyugodtan ismételheted ugyanazt a baromságot párszor.

AliveMOon
Tag

# Elküldve: 2012. Dec. 14. 14:43


SO_SNDBUF és SO_RCVBUF változtathatja meg a normál buffer méretet, mekkorát foglaljon a kimeneti és bemeneti puffernek, ill. a puffer méretével növelhető a nagy mennyiségű adatok forgalma, vagy csökkenthető, hogy korlátozzák a lehetséges bejövő adatok menyiségét. A rendszer megszab egy abszolút határt ezeknek az értékeknek.

Ez igaz vagy nem?
Ezt a tervező írta!

Menet közben azért vezsem le a buffert, mert ha csak telnet cuppogás van, nem kell a nagy buffer, megy szépen TCP_NODELAY . Időnként viszont egy kamera böffent egy nagy képet azt küldöm nagy bufferral.
És ha átment visza rakom kicsire, hátha más socket kér képet.
(zip-elem a kamera képeket mielött küldi, de még mindig 1-2 mega utánna is. Itt tényleg nagy felbontású kamera képekre gondolj, mérésekhez, nem túl praktikus, ha JPG 8x8 as kockák befigyelnek)

Természetesen ha folyamatosan nagy csomagok vannak nem szedi vissza a buffert!

Chain-Q
Divatamigás

# Elküldve: 2012. Dec. 14. 14:49


Hat ez facepalm deluxe. Feladtam. :)

AliveMOon
Tag

# Elküldve: 2012. Dec. 14. 14:55 - Szerkesztve: alivemoon


Quoting: charlie
Szerk:
És mégegyszer *UTOLJÁRA* leírom, hátha nem ment át: az általam leírt problémában kurvára mindegy, hogy mekkorára állítod a TCP buffer értékét.


Nem értem mit mérgelődsz!

Én azt mondom, ha ép kapcsolatod van, nem feltétlen kell a select, a bufferba tolhatod a sendel az adatot. Ha a send azt mondja, hogy elég, azaz kevesebbet ad visza mint bele akartál írni, akkor kell megvárni, hogy mikor alkalmas újra küldésre. És ez a rész függ a buffer mérettől, a send az tudja mekkorára metélheti a csomagokat, nincs összefüggésban, hogy menyit adsz neki oda.

Úgyan ez a helyzet a bufferral, a recv-nél is, a recv folyamatosan mindenféle select nélkül szolgáltat adatot, akkor kell a select amikor 0 adat jön és tudod, hogy jó lenne ha jönne.

AliveMOon
Tag

# Elküldve: 2012. Dec. 14. 15:11 - Szerkesztve: alivemoon


Félre értés ne essék én is először úgy csináltam, select és ha jelez valamit, csinálom amit mond.
De annak az az eredménye, hogy 1%ot sem éri el a hálózati forgalom, bevallom ez így erőszak amit csinálok, de így meg működik mint az állat!
(mások programjában is így láttam)

A másik mondanivalóm az, hogy szerintem másként van implementálva, mint leírva(legalábbis windows-on).
Valamikor a UNIX-os időkben még korrekt volt, aztán tojott mindenki a specifikációra.

Lásd TTL. A leírásban még 1TTL 1ms volt ma meg minden rooter csökkent rajta 1-et oszt csokolom.

AliveMOon
Tag

# Elküldve: 2012. Dec. 14. 15:41


Látod ugye ha írok, ha nem így működne jól, szerintem rég nem tudnék írni, mert mondjuk a BMW egyik szakembere fejbe lő!

ratman
Kék troll

# Elküldve: 2013. Sze. 25. 20:53 - Szerkesztve: ratman


Nah, most mar mint 68k-s RoadShow user azt kell mondanom, hogy egyaltalan nem rossz dolog.

Egyreszt tenyleg fire-and-forget, ha az a vagyad, hogy mindig elinduljon, totalis kussban, mert erre kepes.

Elonyok:
Teljesitmeny: van.
Dokumentacio: van, hasznalhato. :D

"Korszeru" ficsorok: vannak (egesz meglepoen jo).

+1 morphoson is megy. Persze x-surf-100-al nem, de ez nem a roadshow es nem a morphos baja, szerintem. :D

Hatranyok: nincs gui - nabumm, kabe 10 perc alatt eletre tudtam kelteni classic OS-en.

Egy negativ dolog van: van neki bsdsocket.library-ja, amit betesz a libs:-be, emiatt ha esetleg van meg olyan elvetemult allat - mint en - aki RoadShow mellett neha akar meg AmiTCP-t is hasznalni, az szembesulni fog azzal, hogy az AmiTCP nem indul el, mert azt mondja, hogy mar fut. Ezen mukodesnek ez oka. :D

... es ez a hozzaszolas OS3.1-en, RoadShow stacken, IBrowse hasznalataval keszult. :D

Yellow Dog
Tag

# Elküldve: 2015. Jan. 13. 17:55


Szeretném megkérdezni, alap A1200-ason sikerült-e valakinek elérni a netet, elindítani egy böngészőt és használni is azt. Ha igen, hogyan?
Van egy Orinoco Gold Wifi kártyám, feltelepítettem a MiamiDX-et, elméletileg van IP cím is, de sajnos a 2MB memoriából mindössze kb 120kB marad ami már egy ping-hez sem elég, nem egy böngésző futtatásához... :-(

Chain-Q
Divatamigás

# Elküldve: 2015. Jan. 13. 20:08


@Yellow Dog:
A MiamiDx manual azt irja hogy "(minimum) 3 MB of RAM, more recommended." ezzel kb. meg is válaszoltuk a kérdésed. A Miami is sok RAM-ot eszik (bár a GUI kilövésével biztos felszabadul valamennyi), de egyáltalán, egy alap1200 nem alkalmas erre, ebben a formában. Egy webböngészőhöz meg végleg nem. Egy IRC kliens még beférhet, ha ügyes vagy...

Persze 14Mhz és 2MB RAM sok lehet ahhoz képest hogy egy C64-re is van net meg "böngésző", de azok mind speciális, egyedi szoftverek, míg az amigás TCP/IP stackek, a WiFi support, stb mind-mind "egyszerűen" portolt szoftverek máshonnan, ahol jóval több hardver erőforrás van.

Mellékesen egy WiFi támogatás működését még egy 68060 is megérzi (főleg, ha encrypted), hát még az alapgép...

Yellow Dog
Tag

# Elküldve: 2015. Jan. 14. 19:35


Szomorú vagyok... Ezek szerint fast ram nélkül gyakorlatilag nincs mód a netre kapcsolódni, pontosabban a helyi hálózatra. Igazából egy samba szerver elérés a kitűzött cél, egyébre pl. böngészés, maradnék a PC mellett.

Chain-Q
Divatamigás

# Elküldve: 2015. Jan. 15. 00:25


Szomorkodás helyett:

1., Használj vezetékes ethernet kártyát, ahhoz nem kell a WPASupplicant. Gyorsabb, kisebb a memóriaigénye...
2., Használj kisebb memóriaigényű TCP/IP stacket, pl. AmiTCP. Igaz ezt nehezebb bekonfigolni, de cserébe nem is tölti be a MUI-t maga mellé, ami ekkora gépen eléggé számít.
3., Az SMBFS egy apró exe, szerintem annak még illene beférni ezek mellé.

Yellow Dog
Tag

# Elküldve: 2015. Jan. 15. 10:22


A WIFI kártya adott, megpróbálom első körben kikapcsolni a routerben a titkosítást, illetve a 2-es 3-as pontban leírtakat elvégezni, hogy láthassam, működhet-e a dolog.
Köszönöm a tanácsot.

Yellow Dog
Tag

# Elküldve: 2015. Jan. 26. 09:16


Volt egy kis időm, gondoltam kipróbálom az AmiTCP-t, de sajnos csak a demo van fent, és ha jól olvasom a Sana driver csak a "commercial" verzióban érhető el :-( Tudna valaki segíteni, honnan lehet(ne) letölteni?
Köszönöm

Yellow Dog
Tag

# Elküldve: 2015. Jan. 30. 20:25


Megoldódott... ;-)

Feltelepítettem az AmiTCP 4.1-et majd a 4.2 frissítést, beállítottam, a stratnet parancsra viszont az "AmiTCP couldn't be started" hibaüzenetet kapom. Első körben (mert kényelmesebb egyelőre) Winuae alatt szeretném beüzemelni, de a neten nem találok egyértelmű utalást, hogy az uaenet.device-t vagy a2065 z2-t kell kiválasztanom, illetve ehhez melyik devs:... drivert kell Amiga oldalon beállítani?

Köszönöm a segítséget

Yellow Dog
Tag

# Elküldve: 2015. Feb. 01. 10:52


Na, ráment egy napom, természetesen eredménytelenül. Felraktam a 4.3-as patch-et, ezt követően már kiírta, hogy "not valid key file..." Letöröltem az egész könyvtárat, mert uninstall persze nincs, ezt követően viszont már az alap 4.1-es floppyról sem települ, minden file másolásánál kiírja, hogy skipped... azt hiszem elcsomagolom ismét (egy jó időre) az egészet, elment tőle a kedvem rendesen... :-(

Persze még felvetődik bennem jó néhány kérdés mindez mellett, pl. felhasználónév/jelszó párost kér, holott vezetékes LAN-nál erre nincs szükség (Winuae esetén) ha élőben szeretném kipróbálni a WIFI kártyával, ott meg pont kellene a routerhez a "wifi jelszó" amit viszont nem kér beállítani, illetve az SSID-t sem... Nekem eléggé úgy tűnik, hogy ez csak valami ősrégi modemes kapcsolathoz lett kifejlesztve, sehol nem látom a nyomát, hogy egy "sima" helyi hálózatban hogyan tudnám életre kelteni, lehet sehogy...

Chain-Q
Divatamigás

# Elküldve: 2015. Feb. 01. 10:59


1., Az elmúlt pár napban nem volt időm ide válaszolni...
2., Látom erről is kell egy HowTo-t írnom mint a MiamiDx-ről, mert káosz van a fejekben.

ratman
Kék troll

# Elküldve: 2015. Feb. 01. 12:33 - Szerkesztve: ratman


1. Winuae alapból bekapcsolja a bsdsocket.library-t emiatt más tcp sztekk nem fog menni (tehát ki kell kapcsolni és a 2065 emulációt meg be).
2. dobj egy levelet ide (ratmancj<kukacs>dzsíííímél<pötty>kom) és megnézem, hogy konkrétan AmiTCP-vel tudok-e segíteni.
3. A wifi sztekk != tcp sztekk. Arra ott van a prism2.device az aminetről, ami tartalmazza a WirelessManagert, amit kézzel kell bekonfigolni (jó a doksija) és a tcp sztekk (amitcp, miamidx, roadshow, whatever) _ELŐTT_ kell elindítani, mert anélkül nem "él" a prism2.device. :)

Yellow Dog
Tag

# Elküldve: 2015. Feb. 02. 13:42


Quoting: charlie
káosz van a fejekben

Bizony, jó lenne :-)

Quoting: ratman
dobj egy levelet

Írtam, köszönöm.

dh1
Mr. DTP

# Elküldve: 2015. Feb. 06. 09:06


Csinaljunk egy felmerest!

PCMCIA Ethernet Speed Ratings

Az alabbi formaban mindenki irja meg, hogy mennyit visz a cucca, most elso korben csak PCMCIA-s gepeket nezzunk, kesobb nezthetunk nagyvasakat is ...
------
Amiga = (A1200/A600)
CPU = (680EC020@14 / 68000@7.09 / 68030@50 / 68060@66)
Ethernet = cnet.device / 3c589.device / egyéb
TCP/IP = AmiTCP/IP, Miami, GENESiS, Termite (verziószámmal)
Speed = xxx Kbyte/sec

Chain-Q
Divatamigás

# Elküldve: 2015. Feb. 06. 21:24


TCP stackból a Roadshow-t kihagytad. :P Mellesleg a "mennyit visz"-t hogy kell tesztelni? Csak mert pl. a wget az ixemul.library miatt elég nagy overhead, ill. azon is múlik, hogy milyen fájlrendszerre írsz és az hogy van beállítva, stb...

Meg a HTTP protokollnak is van egy overheadje, ráadásul egy TCP kapcsolat automatikusan lassítja magát, ha az egyik oldal nem bírja az átvitelt és packet loss lesz, vagyis ez azt jelenti, hogy mindenképpen valamennyivel a HW korlátai alatt lesz a sebesség. Ha a neten át a tűzfaladon keresztül mérsz, akkor az is bejátszhat, had ne soroljam... :)

Szóval ha összehasonlító mérési eredmény kell, akkor jó lenne a hardveren kívül a mérés módszerét is definiálni...

siz
Tag

# Elküldve: 2015. Feb. 06. 21:34


Ezen én is gondolkoztam, hogy hogyan lehetne mérni. De mivel az A1200-am (és most már a kéznél levő 600-am is) atomjaira van szedve, mert az új kondigarnitúra érkezésére vár, így úgysem tudom letesztelni.
Viszont a fájlrendszert egy >NIL: -tal ki lehet iktatni. :)

werdy
Tag

# Elküldve: 2015. Feb. 06. 22:53


AmiTCP kevesebb memóriát evett ha jól rémlik, A600-on 1mb rammal azt használtam file transferre (pcmcia hálókártyával).

Yellow Dog
Tag

# Elküldve: 2016. Jan. 14. 16:15


A napokban beleszaladtam egy új és olcsó kis kütyübe, egy ESP8266 Wi-Fi modulról van szó, amely beépítve tartalmazza a TCP/IP stack-et.
Szeretném megkérdezni, ha jól értelmezem, ezzel el lehet hagyni pl. a Miami vagy AmiTCP (TCP/IP stacket tartalmazó) progikat esetleg? Úgy értem, nyilván kellene hozzá saját driver, de sima AT parancsokkal kommunikál 115kbs sebességgel. annyi lenne a feladata, hogy egy memória címre, ahová mondjuk a kütyü be van kötve, mennének az adatok és vissza. Ez utóbbi nem probléma, azt nem látom át igazán (mert nem értek ehhez a részéhez), hogy a driver a másik oldallal, tehát a szoftverekkel hogyan kommunikálna?
Ha valakinek volna ötlete, megköszönöm előre, hiszen egy nagyon jó kis kiegészítő lehetne, a fent nevezett két progi elhagyása pedig a memória és erőforrás szűkében álló gépeknek is adna egy esély a netes kapcsolatra, ha mást nem file átvitel, vagy ftp használatát megoldhatná.

Yellow Dog
Tag

# Elküldve: 2016. Jan. 14. 16:16


Majd elfelejtettem, Kínából természetesen 600HUF körüli áron is kapható ;-)

Chain-Q
Divatamigás

# Elküldve: 2016. Jan. 14. 16:25 - Szerkesztve: charlie


TCP/IP stack nélkül maximum null-modem vagy BBS-szerű fájlátvitel működik, FTP biztos nem... Az hogy a TCP/IP stack ethernet kártyán valamiféle soros izén át működik, lényegtelen ez esetben. Az amiga ugyanis ezt a kütyüt egy sima soros átvitelnek látja, hogy utána ez a kütyü nem egy kábel vagy egy mezei modem, hanem áthúzza a hálózaton a soros kommunikációdat, az egy dolog...

Aminek több értelme lenne, valaki a sima 68000 alapú rendszerekre portolhatna valami lwIP vagy uIP alapú stacket, ami tud SLIP-et meg PLIP-et, AmiTCP API kompatibilitással, szóval akkor kis gépekre is lehetne jópofa hálózatos dolgokat rendesen. De persze ez nem user-level taszk.

Yellow Dog
Tag

# Elküldve: 2016. Jan. 14. 16:38 - Szerkesztve: yellowdog


Quoting: charlie
Az amiga ugyanis ezt a kütyüt egy sima soros átvitelnek látja

A soros átvitel hardveresen megoldható, hogy parallel legyen, tehát arra gondolok pontosan, hogy egy driver szerűség kellene ami kapcsolódna a Miami vagy AmiTCP helyett az alkalmazásokhoz, mintegy hidat képezvem, a TCP/IP stack pedig a kütyüben megoldja a netes kapcsolatot. Érthetőbben, pl. a böngészőbe ha beírok a címsorba egy címet, majd Enter, akkor gondolom ez a string átkerül az AmiTCP-hez, amely csomagolja, és küldi a hardver felé, itt azt kellene elérni, hogy ez a string a kütyü felé vegye az útját, amely megaadott memoriacíme(ke)n érhető el és veszi át a string bájtjait, majd a beépített stack felépíti a csomagot és úgy kerül elküldésre és visszafelé megszabadítva a "sallangtól" küldi vissza a bájtsorozatot az adott alkalmazás felé.
Érthetőbben nem tudom sajnos leírni mire is gondolok ;-)

Chain-Q
Divatamigás

# Elküldve: 2016. Jan. 15. 17:13 - Szerkesztve: charlie


Értem én, hogy villanymotor, de neked meg láthatóan fogalmad sincs róla, hogy működik egy TCP/IP hálózat. :)

AliveMOon
Tag

# Elküldve: 2016. Jan. 15. 17:26


Tök mindegy milyen a hardware, soros vagy párhuzamos, pcmci, vagy pci, egy olyan rétegre van szükség ami létre hozza a bsdsocket.librery-t amiből a programok megtudják hívni a select, connect, accept, send, és recv, stb fügvényeket . Ezt csinálja a stack röviden.

AmiTCP-ben láttam AmiTCP-4.0\export\Devs\Networks\rhslip.device-t és rchslip.device-t szerintem előfordulhat, ha jól bekonfigurálod, hogy működik.

thomas^sd
Tag

# Elküldve: 2016. Jan. 15. 18:11


Quoting: dh1
Csinaljunk egy felmerest!PCMCIA Ethernet Speed RatingsAz alabbi formaban mindenki irja meg, hogy mennyit visz a cucca, most elso korben csak PCMCIA-s gepeket nezzunk, kesobb nezthetunk nagyvasakat is ...------Amiga = (A1200/A600)CPU = (680EC020@14 / 68000@7.09 / 68030@50 / 68060@66)Ethernet = cnet.device / 3c589.device / egyébTCP/IP = AmiTCP/IP, Miami, GENESiS, Termite (verziószámmal)Speed = xxx Kbyte/sec


Ez nagyon jó 5let.
Nemsokára küldök eredményt.

<< . 1 . 2 . 3 . 4 . >>
forum.amigaspirit.hu / Classic AmigaOS / AmiTCP vs. Miami
 
 

Powered by web forum software miniBB™ © 2001-2019