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
TCH
Tag

# Elküldve: 2011. Jan. 02. 16:14


Kizárólag kiváncsiságból.
Melyik a jobbik?

Chain-Q
Divatamigás

# Elküldve: 2011. Jan. 02. 17:35


Kezdjük ott, hogy rossz a kérdés. Miamiból kapásból kétféle van ugye, a "sima" meg a MiamiDx. :)

TCH
Tag

# Elküldve: 2011. Jan. 02. 18:38 - Szerkesztve: TCH


És az egyik jobb mint az AmiTCP a másik meg rosszabb?
Mert ellenkező esetben holt mindegy, hány van belőle, ha mind rosszabb/jobb mint az AmiTCP.

De felőlem átnevezhetjük a topicot "AmiTCP vs. Miami vs. MiamiDx"-re.

AliveMOon
Tag

# Elküldve: 2011. Jan. 02. 19:49


Az AmiTCP halál egyszerű felkonfigurálni, csak el kell olvasni a readme-t, kb. három sort kell saját konfigurációhoz igazítani és megy.

TCH
Tag

# Elküldve: 2011. Jan. 03. 14:00


Hát itt igazából én ilyen összehasonlítgatásokat, meg az ezekre vonatkozó véleményekre lettem volna kiváncsi.
Én pont a Miamiról hallottam, hogy könnyű konfigni.

Chain-Q
Divatamigás

# Elküldve: 2011. Jan. 03. 14:57


Nekem csak a MiamiDx-szel van közvetlen tapasztalatom classicon, de az biztos, hogy többet tud mint az AmiTCP (pl. PPPoE support, firewall, NAT, stb). A tudásához képest tényleg egyszerűen konfigolható egyébként, sírnék a boldogságtól, ha mondjuk egy Linuxban ilyen advanced dolgokat (pl. firewall rule-ek, sysctl hálózati paraméterek, hardver MAC override, stb.) is ilyen egyszerű, átlátható GUI-n lehetne megoldani. Ezen kívül van egy plugin interfész hozzá, amihez többféle kényelmes panel-plugin készült, amelyek hálózati statisztikát és interface-ek online/offline-ba rakását biztosítják kényelmesen. Ez utóbbinak főleg a dialup-os időkben volt nagy súlya, de jelenleg is marha kényelmes, ha pl. A1200-ban ki kell húzni a hálókártyát mondjuk mert egy CF olvasót akarsz bedugni.

A másik oldalon viszont, a MiamiDx hirhedt arról, hogy haza próbált beszélni sokáig, és van néhány kimondottan idegesítő bugja (pl. a DHCP hajlamos elhalni néha, és csak reboot segít).

Az AmiTCP sokkal egyszerűbb szerzet, főleg fix IP-s, egyszer bekonfigolt otthoni hálózatokhoz való bármiféle tűzfal és egyébés konfig fájlt kell hozzá szerkeszteni, bár mintha classicra is készült volna hozzá config GUI, de azokat nem ismerem. Az AmiTCP egyébként "Netstack"-re átnevezve és némiképp továbbfejlesztve jelenleg a M****OS IP stackjeként szolgál.

Sebességre a kettő kb. ugyanott van, az AmiTCP egyszerűsége miatt általában kicsit gyorsabb tud lenni, annak ellenére, hogy a MiamiDx a SANA-II mellett saját MNI formátumú drivereket is támogat, és jónéhány Zorro-s kártyához jár is mellé a driver.

TCH
Tag

# Elküldve: 2011. Jan. 03. 19:00


Tehát akkor nincs konkrét javaslat, mert mind a kettő jó arra amire való.
Mit jelent az, hogy hazabeszél? Kémkedik az user után, vagy csak küld egy jelet, hogy itt egy Miami user.

Chain-Q
Divatamigás

# Elküldve: 2011. Jan. 03. 20:03


Valami userinfókat küldött régen, de aztán mintha az kikerült volna (állítólag) az utolsó verzióból. De mindegy is, mert a készítő honlapja réges rég nem él, szóval már nincs nagyon hova hazabeszélnie, ha akarna is...

Chain-Q
Divatamigás

# Elküldve: 2012. Dec. 11. 20:15 - Szerkesztve: charlie


Úgy tűnik a topic nevében is szereplő két IP stack mellé hamarosan egy harmadikat is kaphat a classic Amiga:

Az Olaf "Olsen" Barthel által készített, eddig az OS4 TCP/IP stackjeként ismert Roadshow 2013. januárjában fizetős szoftverként megjelenik 68k-ra is. Demo verzióban már le is tölthető a kiadást levezénylő APC&TCP oldaláról.

Ezzel hosszú-hosszú évek után újra támogatott hálózati alrendszert kapnak a classic gépek.

Az "új TCP/IP stackről" amigás fejlesztői körökben már akkoriban szóltak hírek, mikor bő tízenpár éve az OS4 fejlesztése elkezdődött. Végül a Hyperionnak exkluzív szerződést sikerült kötnie a Roadshowra - így semmilyen más platformra nem jelenhetett meg - eddig. Olaf Barthel már tavaly is emlegetett egy lehetséges kiadást, de akkor még nem lett belőle semmi, most viszont úgy tűnik igen.

A 68k-s Roadshownak sok előnye és viszonylagos frissessége mellett lesz egy igen jelentős hátránya is: grafikus felület nem fog járni hozzá, csak parancssorból és szöveges állományokkal vezérelhető, akárcsak az egykori AmiTCP, lévén az OS4-ben lévő hozzávaló konfigurációs UI OS4 specifikus.

dh1
Mr. DTP

# Elküldve: 2012. Dec. 11. 21:17


ennek mi ertelme?

ratman
Kék troll

# Elküldve: 2012. Dec. 11. 21:23


Mondjuk annyi, hogy a miami 12+ éves, az AmiTCP meg sokkal több. Azóta azért az ipv4 is fejlődött. :)
A miami sem jó, az amitcp sokkal jobb, persze a konfigolása az rémálom, de ha esetleg 68k-n még ettől is jobb lesz akkor én annak csak örülni fogok. :)

Chain-Q
Divatamigás

# Elküldve: 2012. Dec. 11. 22:01 - Szerkesztve: charlie


@dh1:
Minek mi értelme? Hogy kiadnak egy warét classic Amigára, ami mindig is létezett classicra, csak eddig jogi lófaszjóskaság miatt nem jelenhetett meg?

Amúgy meg lásd amit Ratman mondott. Az IPv4 sokat változott az elmúlt évtizedben és architektúrálisan valószínűleg még mindig a Roadshow a leginkább up-to-date IP stack.

dh1
Mr. DTP

# Elküldve: 2012. Dec. 11. 22:34 - Szerkesztve: dh1


mert mivel is tud tobbet?
vagy kerdezhetnem, hogy mire nem eleg egy Miami classic-on?

Chain-Q
Divatamigás

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


1., A MiamiDx ha nincs hozzá saját kulcsod, már sosem lesz legális.
2., Van benne néhány súlyos bug, pl. a TCP window scaling túl gyors gépeken a forgalmazott adat sérülését okozhatja, a DHCP requestek sikertelensége lefagyást okozhat, stb, ezeket már sosem fogják javítani.
3., A MiamiDx TCP/IP implementáció specialitásai miatt van benne néhány hálózati bottleneck (ami egyébként a 68k-s AmiTCP-re is igaz), pl. hogy a bsdsocket.library select() függvényének timeoutja a VBlank interruptra van felaggatva, ami eleve nem teszi lehetővé bizonyos mennyiségnél (20-30K/sec) több adat forgalmazását másodpercenként, ha a round-trip nagyobb mint 1/50 másodperc.

Szóval maradjunk annyiban, hogy az amigás hálózati stackeknek van bajuk, és lenne mit tuningolni rajtuk... Valaki megpróbálta és most kiadja. Ha neked nem kell, ne használd. Elég egyszerű. :) (Én sem fogom megvenni, de attól még hírértéke van.)

dh1
Mr. DTP

# Elküldve: 2012. Dec. 12. 19:17


nah meg egyszer, ezek hol voltak eddig gondok Classicon?
sehol ...
Mindenkinek van Miami, kulccsal es vidaman hasznalja ...
Ketlem, hogy a fizetos stack nagy keresletet generalna ... foleg ilyen fapad verzioban.
Esetleg egy normalis, guis verzioert adnek penzt ...

ratman
Kék troll

# Elküldve: 2012. Dec. 13. 10:14


@dh1: Nem véletlenül használtam amitcp-t az amiga.rulez.org-on. Az sem volt olyan húdejó, de legalább ment. A Miami kliensnek még elmegy, bár néha érdekes, de legalább van csecse guija. :D

Chain-Q
Divatamigás

# Elküldve: 2012. Dec. 13. 13:06 - Szerkesztve: charlie


@dh1:
Ezek a gondok eddig is megvoltak azoknak akik az átlagosnál hardcorébb hálózati felhasználók, neadjisten fejlesztők amigán. Pl. én napokat szoptam a fent említett select() buggal, miközben tavaly az Ustream hálózati library-ját próbáltam Amigára portolni, tesztcélból.

Pl. még az is felmerült, hogy csak ezek miatt az lwIP nevű mini-IPstacket portolom Amigára, de aztán nem került rá sor (főleg időhiány miatt, mert mert pl. IPv6-ot ugyan tud, de a szintén fontos TCP Window Scalinget (akkor még?) nem tudta.

A GUI-t meg pont leszarom, ha jól működik a stack, a mai DHCP-s, automatán beállítós környezetben amúgy sem sűrűn kéne látnod. A GUI-ról amúgy annyit, hogy úgy tudom a Roadshow-t annó az Amithlonban is akarták, mint új IP stack és készült hozzá egy 68k-s beállító UI is, még bőven az OS4-es idők előtt, de mivel azt más csinálta, ezért azt nem tartalmazza ez a csomag. Szóval még az is lehet, hogy később lesz hozzá.

De én nem akarok érvelni a Roadshow mellett, csak örülök, hogy mostantól még több választási lehetőség van, és mindenki kiválaszthatja ami neki a legjobb.

AliveMOon
Tag

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


A select() az csak annyit csinál, hogy le tudod kérdezni melyik socketre érkezett adat, vagy a send képes küldeni, vagy listenernél akar e valaki csatlakozni.
Az adat átvitelhez semmi köze, elég jó megoldás, hogy vblank függő(csak mai szemmel ritka), még szerencse, legalább nem öli meg a gépet az állandó select()telés.

A buffert kell felnyomni akkor nő az adat átvitel, próbáld ki!

Hiába van gigabit hálozat kicsi buffert adsz nem fog szakítani, egy gigabitet kel oda adni neki és akkor megy(sajnos ilyen szarul konstruálták meg)!
Ez abszolúte memória függő!

Chain-Q
Divatamigás

# Elküldve: 2012. Dec. 13. 20:43 - Szerkesztve: charlie


@AliveMOon: Ennyit tudok hozzádfűzni. Nem csak a fenti megszólalásod miatt, hanem úgy amit huzamosan előadsz itt a fórumon most már egy ideje. Én kérek elnézést.

(Ps: annyira képzeletbeliek a fenti select() "abszolute memória függő" bugok pl. az AmiTCP-ben és amúgy a VBlank annyira tökjó megoldás, hogy a MorphOS 3.0-ban jelentős módosítások történtek a(z AmiTCP alapú) NetStackben, hogy kijavítsák. Én nyilván nem értek hozzá, de nyilván aki tövig túrt az IP stackben az én bugreportom alapján, hogy kijavítsa, az is csak beképzelte az egészet. Meg utána az userek is beképzelték a teljesítménynövekedést.)

dh1
Mr. DTP

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


En meg ennyit se ertek hozza, de hol es hogyan lehet buffert adni? :)
Kiprobalnam! :)

AliveMOon
Tag

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


charlie

Hát lehet szociopata vagyok de nem értem, mi van?

Első paragrafusban leírtam mit csinál a select!
Utána meg tanácsoltam, egy dolgot, hogy próbáljátok ki, hogy a socket opcioknál a socket bufferét állítsátok a lehető legnagyobbra és akkor elkezd nagyobb sebességgel dolgozni a kommunikáció!

Ezt mind azért mert énis azzal szóptam régebben, hogy hiába selecteltem, sendeltem vagy receiveltem többet kevesebbet nem változott semmi, aztán mérgemben adtam neki rengeteg memóriát, és csodák csodája elkezdett hasítani a hálózat!

Erre írtam, hogy adni kell neki nagy buffert és megy.

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, const struct timeval *timeout);

Inputok:
nfds - hány socket van a leíróban
Outpot:
readfds - megkapod melyik socketekbe érkezett adat
writefds - megkapod melyik socketekbe tudsz írni
exceptfds - melyik socket dobott kivételt
timeout - nem érdemes magasra állítani, mert blockolja a szálat enyi ideig (0) nem blockol semmit

Ezt nem érdemes a szükségesnél többet hívni, mert
Egy kliens:
sima connect

legtöbben nem is használnak select()-et mert feleslegesnek tartják, tolják az adatot és kész, legfeljebb hápog a send vagy nem jön semmi a recv-ben!

Egy server:
Létre hozunk egy listener socketet
és ha van olvasni való, akkor érdemes egy accept fügvényt le futtatni.
az accept ad egy friss socketet amiben egy kliens csatlakozott.

Én azt szoktam csinálni, hogy elküldöm a saját protokolomban a teljes csomag méretét és ha az nagy akkor felfele korigálom a socket bufferét, hogy gyorsan átjöjjön és utánna meg vissza állítom, hogy a többi socketnek is jusson hely.


A select egy hasznos függvény arra, hogy tudd melyik socket használható valamire, de a send és a recv fogja megmondani menyit tudott átvinni.

AliveMOon
Tag

# Elküldve: 2012. Dec. 14. 10:18


dh1
Az a probléma én csak C-ben tudom.
Az amiga1200-asomon én AmiTCP-t használok és annak a teljesítménye nekem bőven elég volt! Nem kellet megnéznem! De mindjárt megnézem a leíró fájlokat, szerintem benn lesz, egy szám amit feljebb kell állítani.

AliveMOon
Tag

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


Ha jól sejtem AmigaTCP-vél lesz egy TCP: device, talán a hagyományos addbuffer meg felelhet neki.

Jóbban átgondolva!
Ezt nem is a TCP/IP stack állítgatja, a böngésző, ftp stb. saját hatáskörben állítja be a socket opcióit.

És pediglen itt:
http://amiga.sourceforge.net/amigadevhelp/phpwebdev.php?keyword=getsockopt&funcgroup= GeekGadgets&action=Search

SO_SNDBUF - set buffer size for output
SO_RCVBUF - set buffer size for input

Úgy hogy a böngészőben kell kutatni egy olyan csuszka vagy input utána, ahol az átviteli sebességre utaló kérdés van.

Chain-Q
Divatamigás

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


@AliveMOon: Utolsó hozzászólásom - hozzád - a kérdésben.

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.

2., ha a TCP/IP stack nem támogatja az RFC1323-at (TCP Extensions for High Performance) - pl. AmiTCP, vagy alapból ki van kapcsolva - pl. MiamiDx, akkor ez azt jelenti, hogy egyszerre maximum 64k adat lehet úton a két szerver között, mivel többet egyszerűen képtelen leírni a TCP protokoll alapból, ami akkor probléma, ha a szerverek nagyon távol vannak (pl. innen japán vagy nyugati parti, vagy ausztrál szerverrel akarsz kommunikálni), ezért a round-trip ideje magas, emiatt sok adat "beragad" a bufferbe, amíg a hozzá tartozó ACK-ok meg nem érkeznek, ez pedig alkalmazás oldalon azt okozza, hogy a send() beblokkol, hiszen folyamatosan tele a buffer.

3., Ha pedig ezt úgy akarod workaroundolni, hogy select()-et használsz, alacsony timeouttal (pl. 1-2ms) hogy közben a programod hálózati szálja ne blokkoljon be a felszabaduló bufferekre várakozó send()-ektől, akkor az a probléma merül fel, hogy a select() 68k-s IP stackokon vagy azonnal képes visszatérni (0 ms timeout), vagy _MINIMUM_ 20ms (egy vblanknyi idő) várakozás lesz a select() visszatéréséig. Ez azt jelenti, hogy az ugyabban a loopban lévő send() maximum 50x tud lefutni, ami azt okozza, hogy ha pl. 512 byte-os darabokat írsz a socketre akkor az elméleti maximum amit a fenti problémák miatt elérhetsz, az 25Kbyte/sec, AKÁRHOVA állítod a socket buffer méretét, akkor is. (MiamiDx-el amúgy a fenti scenarioban még rosszabb a helyzet, mintha a MiamiDx még hosszabb minimum visszatérési idővel dolgozna.)

4., A modern TCP/IP stackok egyébként maguktól is állítják a socket recv/send buffer méretét attól függően, hogy mekkorára van igény, az általad megadott érték maximum javaslat, vagy az elején gyorsítja a kommunikációt, amíg az IP stackek le nem beszélik, hogy nagyobb bufferre van szükség (de ha az egyik oldal nem támogatja a TCP Window Scalinget, akkor sosem fog 64k fölé menni).

A select() manualt olvastam, hiába pasteled be még huszonötször. A MorphOS 3.0-ban a fenti select() timeout issue-t kijavították, még ha az RFC1323-at továbbra sem támogatja a stack.

Chain-Q
Divatamigás

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


@dh1:
MiamiDx alatt - csak regisztrált MiamiDx esetén - a socketek alapértelmezett send és receive bufferének beállítása, valamint a fent említett RFC1323 bekapcsolása a Database -> SysCtl fülön történik. Lásd a mellékelt ábrát. A socket buffer default méreteket 32k fölé nem érdemes növelni, mert problémákat okozhat egyes szerverekkel vagy alkalmazásokkal.


1. ábra, így tedd tönkre a MiamiDx-ed beállításait

Szerk:
MorphOS alatt NetStack-ben pedig az ENVARC:Sys/Net/NetStack.config-ban állíthatók be a szükséges opciók. Itt mehetünk feljebb is, de ne menjünk el 64k-ig. Az ábrán látható opciókkal az OWB pl. jobb teljesítményt ad, a tapasztalatok szerint. Az RFC1323-at a NetStack nem támogatja.


2. ábra, így tedd tönkre a NetStack beállításait

Mivel a NetStack gyakorlatilag egy fejlettebb AmiTCP, így elképzelhető, hogy az AmiTCP-nek is van valami hasonló konfigfájlja, ahhol ezek beállíthatók, de azt nem tudom fejből.

Szerk#2: Ez a FAQ arra utal, hogy az AmiTCP opcióit az AMITCP:db/amitcp.config -ban kell állítgatni. A szükséges opciók formátuma valószínűleg ugyanaz mint NetStack esetén, de ez durván untested, csak tipp.

AliveMOon
Tag

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


charlie

A socket gyártja az teáltalad említette csomagokat az tényleg max 64k lehet, a socketnek lehet adni az általam említett buffert amiben össze darabolja vagy helyreállítja az adatot.

Nem ugyan arról beszélünk.

Én azt írtam, hogy legtöbben nem szoktak használni selectet.

Én szoktam!

Én nem használtam soha MiamiDX-et mert Amineten ott volt az AmiTCP, bekonfiguráltam és ment!

Harmadszor meg azt írtam, hogy miként állítja a getsockopt és setsockopt-ot az a böngésző és FTP program kezeli, a TCPstack végre hajtja.

Chain-Q
Divatamigás

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


@AliveMOon: Értem, hogy miről beszélsz, csak kurvára senki nem kérdezte, ezeket a témákat te hoztad fel, mint ellentmondást arra amiről én beszéltem, holott kurvára semmi köze hozzá, és most te vagy meglepődve?

Quoting: AliveMOon
Harmadszor meg azt írtam, hogy miként állítja a getsockopt és setsockopt-ot az a böngésző és FTP program kezeli, a TCPstack végre hajtja.

Ami egyébként nem feltétlenül igaz, ezek az opciók stack szinten is állíthatók, és a programnak nem feltétlenül kell kezelnie, lásd a mellékelt ábrákat fent, sőt a modern TCP stack implementációk általában nem is kezelik szentírásként, amit a program beállít nekik... Ráadásul ez egyáltalán nem Amiga specifikus, a MiamiDx pl. a BSD rendszerek /etc/sysctl.conf-jának tartalmát mappolja ki abba a beállítási ablakba (mivel a MiamiDx magja egy régebbi FreeBSD stack portja). Linuxon, OSX-en szintén van ugyanilyen, szerintem Windowson is állíthatók ezek az opciók valahol mélyen a registryben...

Befejezted, vagy a maradékot is szedjem atomjaira amit írtál?

AliveMOon
Tag

# Elküldve: 2012. Dec. 14. 11:53


Quoting: charlie
3., A MiamiDx TCP/IP implementáció specialitásai miatt van benne néhány hálózati bottleneck (ami egyébként a 68k-s AmiTCP-re is igaz), pl. hogy a bsdsocket.library select() függvényének timeoutja a VBlank interruptra van felaggatva, ami eleve nem teszi lehetővé bizonyos mennyiségnél (20-30K/sec) több adat forgalmazását másodpercenként, ha a round-trip nagyobb mint 1/50 másodperc.


Én csak ezt fejtettem ki, hogy a selectnek nem sok köze van a max 20-30k hoz!
Vagy nem?

Chain-Q
Divatamigás

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


@AliveMOon: De van. Az eddigi írásaimban megtalálod a válaszokat is. Kb. két és félszer írtam le, különböző módokon. Ha még mindig nem érted, akkor nem tudok mit mondani. És nem is akarok.

AliveMOon
Tag

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


SO_SNDBUF and SO_RCVBUF
are options to adjust the normal buffer sizes allocated for output and input buffers, respectively. The buffer size may be increased for high-volume connections, or may be decreased to limit the possible backlog of incoming data. The system places an absolute limit on these values.

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.
Megfelelően fordítottam a bsdsocket.library ide vonatkozó passzusát?

Tehát ha fel tudod nyomatni a buffer méretet, kevesebbet kell selectelned. Én meg ezt mondtam végig!

A select, send és recv-t az alkalmazás hívja és ő állítja a socket opcióit, amenyire a stack engedi. Tehát ha nagyobb buffert tud engedéjezni, az socket részére, elég kevesebbet, vagy ugyan annyit selectelnie az alkalmazásnak, hogy növekedjen az adat átvitel.

Töled azt is olvastam, hogy szivtál a selectel, nem lehet, hogy most ez az infó segít?

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

Powered by online community software miniBB™ © 2001-2024