Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorgorgh
   • CommentTime22 Mar 2024 17:03

    
   Serwus,
   Gdy próbuję załadować jakieś większe programy z sieci za pomocą Fujinet 1.5 to w 90 procent przypadków mam błąd odczytu i nic się nie wczytuje. Z mniejszymi plikami urządzenie sobie jakoś radzi. Moje pytanie czy też macie podobnie i czy jest na to jakaś rada? Rozmawiałem z Thomasem i on mówi, że to raczej nietypowe zachowanie, ale z tego co pamiętam to jak miałem pożyczonego Fujineta od Stringa to efekt był podobny do opisanego.
2. • 2: CommentAuthortebe
   • CommentTime22 Mar 2024 17:03

    
   udostępnić Wifi na komórce, którą postawisz obok FujiNet-a
3. • 3:
      
     CommentAuthorPecus
   • CommentTime22 Mar 2024 17:03

    
   UDP się kłania...
4. • 4:
      
     CommentAuthorPeri Noid
   • CommentTime22 Mar 2024 18:03

    
   Według specyfikacji protokół TNFS, którego używa FN, potrafi pracować również na TCP. Problem w tym, że to nie zostało zaimplementowane - dostępny serwer co prawda akceptuje połączenia TCP ale dalszy kod z nimi związany ma pusty. Gdyby to dokończyć, można by było przejść na TCP i mieć problem z głowy (napisałem sobie proxy tłumaczące do tego celu UDP na TCP ale utknąłem przy braku kompletnej realizacji TCP po stronie serwera).
5. • 5:
      
     CommentAuthorMq
   • CommentTime22 Mar 2024 19:03

    
   Potwierdzam lipę z UDP. Ja z tego powodu praktycznie używam Fujineta głównie do tego, żeby leżał w szufladzie.
6. • 6: CommentAuthorAdam
   • CommentTime22 Mar 2024 19:03

    
   Wydawało mi się, że to już było omawiane w wątkach dotyczących FujiNetu, ale chyba wiedza się nie rozpropagowała.
7. • 7:
      
     CommentAuthorMq
   • CommentTime22 Mar 2024 19:03

    
   Nie rozpropagowała się, bo problem dotyczy połączeń, w których ginie dużo pakietów i muszą być powtarzane często. Z tego powodu wszelkie stałe łącza internetowe ze stabilną transmisją chodzą w miarę dobrze pod tym względem i duża część użytkowników w ogóle nie zgłasza żadnego problemu, a przy połączeniach komórkowych Fujinet niestety w moim odczuciu nadaje się do użycia słabo. Niestety chyba komórkowcy to na tyle nisza, że zostałem generalnie olany, więc Fujinet leży w szufladzie i czeka na jakieś lepsze czasy. Samo urządzenie jest fajne, ale albo ja się przeprowadzę gdzieś gdzie będę mógł tego używać, albo znajdzie się ktoś komu będzie ten problem doskwierał i będzie umiał i chciał to oprogramować od nowa na sensownych protokołach.
8. • 8: CommentAuthormono
   • CommentTime22 Mar 2024 21:03 zmieniony

    
   VPN-y używają UDP - może gdyby kierować komunikację przez porty przez nie używane, to routery komórkowe by to lepiej przepuszczały i komunikacja była stabilniejsza?
   
   Edit: Da się postawić gdzieś serwer proxy do Fujinetowych który by słuchał na portach od VPN?
9. • 9:
      
     CommentAuthorPecus
   • CommentTime22 Mar 2024 22:03 zmieniony

    
   To nic nie da.
   
   W przypadku VPNa pracującego po UDP o poprawność danych (korekcję błędów, powtarzanie ramek itp.) dbają protokoły które są głębiej i dla których UDP jest tylko nośnikiem.
   I jeśli wymagane jest powtórzenie ramki TCP to jest ona powtarzana i już.
   Tyle że dla działającego wyżej (niżej? :) ) protokołu UDP to są inne dane w tym samym strumieniu - on nie ma pojęcia, że powtarza jakąś błędnie odebraną ramkę. Samo UDP nie dba o tego typu "drobiazgi".
   
   P.-S. Jak tak siebie czytam, to sam nie wiem czy bym zrozumiał :P
10. • 10:
       
      CommentAuthorjhusak
    • CommentTime22 Mar 2024 23:03

     
    Ech, mój Fujinet też się kurzy z ww powodów. Być może dlatego, że mam 2 routery albo jeszcze z innego powodu. Nie rozumiem tego przypięcia do UDP. Rozumiem, że TCP/IP jest trochę bardziej skomplikowany w implementacji, ale to już zostało zrobione przecież.
11. • 11:
       
      CommentAuthorPecus
    • CommentTime22 Mar 2024 23:03 zmieniony

     
    Ja to gdzieś kiedyś opisywałem (choć to były bardziej domysły, ale mające poparcie w faktach).
    Otóż cały FujiNet jest kopią (no dobrze ... wywodzi się :) ) z rozwiązania dla ZX Spectrum (Spectranet??).
    Tyle tylko że w FujiNecie zastosowany został moduł WiFi posiadający stos TCP w przeciwieństwie do rozwiązana Spectrumowego.
    
    Spectrumowcy musieli by implementować TCP na poziomie samego Spectruma a to nie jest takie proste, jak się nie ma sporego bufora i szybkiego procka.
    W związku z tym zrobili komunikację po UDP, który to protokół tego wszystkiego nie wymaga i tak powstał TNFS.
    
    A koledzy od FujiNeta poszli na łatwiznę i po prostu skopiowali to rozwiązanie mimo, że zastosowany moduł ESP ma stos TCP na pokładzie!
    
    A teraz.... wg mnie jest już trochę za późno. Bo przywiązanie do UDP jest na najniższym poziomie. Trzeba by więc wywrócić trochę projekt. No ale wtedy można by wbijać się po prostu na standardowe serwery FTP, a nie stawiać jakieś dziwne rozwiązania rodem z ZXa by mieć serwer z plikami dla Atari.
    ->link<-
    Wyraźnie piszą, że to służy do komunikacji PC -> Spectrum :P
12. • 12: CommentAuthormono
    • CommentTime23 Mar 2024 00:03 zmieniony

     

    Pecus:

    W przypadku VPNa pracującego po UDP o poprawność danych (korekcję błędów, powtarzanie ramek itp.) dbają protokoły które są głębiej i dla których UDP jest tylko nośnikiem.

    No oczywiście, UDP to protokół bezstanowy i nie ma sesji jak TCP, poza tym nie ma gwarancji dostarczenia pakietu (milion razy to już pisano). Chodziło mi o problemy z odrzucaniem/gubieniem paczek przez routery które mogą występować po drodze, co zależy od polityki providera. Trudno mi uwierzyć że paczki dla VPNów nie są przepuszczane przez sieci komórkowe (rozumiem, że inne porty mogłyby być blokowane żeby optymalizować ruch). A Fujinet nie powtarza requestów? Przecież samo SIO to robi.
13. • 13: CommentAuthorpigula
    • CommentTime23 Mar 2024 09:03

     
    Używałem Fujinet'a z łączem t-mobile (jak nie miałem jeszcze światłowodu) - bardzo słabo to działało. A łącze miałem całkiem dobre - bo bez problemu korzystałem z platform streamingowych takich jak netflix czy hbo. Kilka starych programów pod tą zabawkę wymaga otwartego portu, co dla osób pracujących na łączach mobilnych jest nieosiągalne. Z tego co pamiętam żadna z firm mobilnych nie oferuje publicznego adresu, a to też duży minus.
14. • 14: CommentAuthorgorgh
    • CommentTime23 Mar 2024 11:03

     
    Co najśmieszniejsze ja mam światłowód A mimo to problemy nadal występują
15. • 15:
       
      CommentAuthorMq
    • CommentTime23 Mar 2024 11:03 zmieniony

     
    Ja mam internet w play. Router LTE. Używam tego od wielu lat już i wszystko śmiga. Transfery na poziomie 5-8Mbit to norma. Do routera mam wpięte 3 kompy po kablu i często na raz wszyscy oglądają youtube w 720p bez problemu, a nawet w HD, nieraz jeszcze równolegle po wifi dołączają się dwa telefony i też coś gmerają po necie. W tym czasie pracuję u klientów na pulpitach zdalnych, a z jednym klientem łączę się przez VPN i dopiero pulpit zdalny do serwera. Wszystko to śmiga elegancko i nie mam żadnych zacięć ani błędów w połączeniach.
    
    A Fujinet łączy się mi na tym beznadziejnie. Raz się połączy, ale jak wejdę w jakiś katalog na serwerze, to już nie chce wyświetlić zawartości. Potem raz się połączy i coś odpali, ale za drugim razem już nie chce. Nieraz w ogóle nie chce się połączyć z żadnym serwerem, a czasami jest tak, że tylko z jakimś jednym serwerem się łączy, a z innymi nie chce. Odpalanie większych plików kończy się tak jak u gorgha w pierwszym poście. Wyraźnie winne są protokoły i gówniane rozwiązanie źle zaprojektowane przez twórców Fujineta. A sam fujinet sprzętowo działa dobrze, bo jak sobie lokalnie postawię serwer na kompie w sieci lokalnej, to Fujinet mi śmiga z tym serwerem jak dziki.
16. • 16:
       
      CommentAuthorpirx
    • CommentTime23 Mar 2024 14:03

     
    tak mi mignęło jakoś na fujinetowym fejsbuniu, że dodają ftp. tak naprawdę to ta dyskusja szła 3 lata temu i Thom pisał, że pokaże, gdzie dłubać, bo sam wszystkiego nie zrobi. niestety ktoś musiałby poświęcić (wiele) dni, żeby to ogarnąć, nikt się wtedy nie garnął tylko przyganiał kocioł garnkowi, a ty trzebaby przygarnąć.
17. • 17:
       
      CommentAuthorPecus
    • CommentTime23 Mar 2024 14:03 zmieniony

     
    Ja tam się nie znam na programowaniu tego, więc tylko przyganiam :)
    
    FTP chodzi po TCP więc... wracamy do punktu wyjścia naszej dyskusji Chyba że chcą zrobić FTP po UDP :) - no to moje najszczersze...
18. • 18:
       
      CommentAuthorMq
    • CommentTime23 Mar 2024 15:03

     
    Ja też się nie znam na oprogramowaniu tego. Ale ktoś wpadł na pomysł żeby zrobić takie urządzenie, to jak robi, to niech zrobi dobrze, a nie tak, że tylko zawód sprawia tym, którzy się podjarali.
    
    W ogóle drażni mnie takie podejście, że coś jest źle, więc następuje słuszna krytyka, a na to odpowiedź jest taka, że to ten krytykant jest zły, bo sam to nic nie zrobił, ale krytykować umie.
    
    Kurde, od krytyki jest odbiorca, a od robienia twórca. W przeciwnym razie jedzmy gówno i bijmy brawo kucharzowi, bo nikt tego gówna nie przyprawił, a on tak, więc mu się należy chwała. A jak się komuś nie podoba, to niech sam sobie zrobi gówno i przyprawi po swojemu, bo kucharz nie ma czasu na to.
19. • 19:
       
      CommentAuthorpirx
    • CommentTime23 Mar 2024 18:03

     
    nie zgodzę się. mam w usa fujinieta od kiedy się pojawiły i nigdy nie miałem żadnych problemów. specjalnie łączyłem się przez hotspot do komórki wiele razy. może tutaj mają lepsze udp, może sieci są nowocześniejsze (bo później wprowadzone niż w europie, nie wiem).
    tak czy siak ten problem w usa nie występuje.
    projekt jest open source. główny programista oferuje, że pokaże, gdzie trzeba zmieniać, jednocześnie nie mając żadnego powodu, żeby z tym walczyć.
    to gówno smakuje dobrze z tej strony kałuży. handluj z tym.
20. • 20:
       
      CommentAuthorPecus
    • CommentTime23 Mar 2024 19:03

     
    Po prostu masz szczęście.
    
    Serwery do których się wbijasz mają do Ciebie dobrą trasę, mało hoopsów i dobre łącza po drodze.
    
    Możliwe też, że miewasz drobne błędy transmisji, ale przy całkowitym braku kontroli Atari po prostu wczytuje i uruchamia taki plik i jak błędne dane nie składają się na kod, to możesz tego nie zauważyć nawet.
    
    Jak gorgh postawi u siebie serwer z jakim dobrem, którego będziesz potrzebował zaczniesz narzekać :)
21. • 21:
       
      CommentAuthorPeri Noid
    • CommentTime23 Mar 2024 20:03

     
    Błędy transmisji UDP wyłapuje, ma w nagłówku sumę kontrolną. Tylko taki uszkodzony pakiet jest po prostu wyrzucany. Sam klient TNFS z FujiNet wykona w takim momencie retransmisję żądania danych po 2s od wysłania poprzedniego. Po 10 żądaniach retransmisji zwraca błąd. Także nie ma tak źle. Ale dobrze też nie jest - jak serwer jest uparty albo routery po drodze są wredne to problem będzie występował. A wredne mogą być np. tak, że odpowiedź przychodzi z opóźnieniem rzędu kilku sekund (serio) - taki tarpit.
    
    Ja osobiście mam całkiem dobre połączenia wiec problemów do głównych serwerów nie obserwuję. Ale powyższe informacje zebrałem dzięki analizie ruchu z serwerem, który mi kolega wystawił na słabym łączu i co do którego było wiadomo, że będą kłopoty - i były. Ale to pozwoliło poznać zachowanie.
22. • 22:
       
      CommentAuthorPecus
    • CommentTime23 Mar 2024 21:03 zmieniony

     
    W teorii więc nie jest tak bardzo źle jak jest, ale jest jeszcze przypadek szczególny.
    
    W przypadku odległych połączeń z dużymi opóźnieniami, datagramy UDP mogą zostać odebrane w innej kolejności niż były nadane!
    Ciekawe jak wtedy sobie to poradzi (a zakładam, że nie poradzi sobie).
    
    Jeszcze raz napiszę.
    A wystarczyło użyć gotowego stosu TCP z zastosowanego modułu WiFi, a nie kopiować złe rozwiązane (choć w przypadku Spectanetu nie było ona aż tak złe, bo tam sprzęt nie ma stosu TCP).
23. • 23:
       
      CommentAuthorPeri Noid
    • CommentTime23 Mar 2024 22:03

     
    Akurat tutaj o tyle nie ma problemu, że protokół TNFS jest typu ping-pong. Czyli klient żąda kolejnego pakietu, a serwer odsyła jedną paczkę (jeden pakiet). Rozmiar pakietu jest przy tym dobrany tak, żeby nie było problemu z fragmentacją. Także akurat tu nie ma problemu. Jest za to oczywisty problem z wydajnością. Znaczy, w normalnym systemie by był ale przy naszych 8-bitowych komputerkach to wiele nie robi.
    
    Owszem, mogli użyć TCP. Aczkolwiek najwyraźniej chodziło o to, że był gotowy serwer (no, połowicznie bo nie ma zaimplementowanego poprawnie TCP, chociaż protokół to zakłada) i do niego dobrano resztę. Poza tym protokół TCP wprowadza spore obciążenie, zarówno pamięciowe jak i obliczeniowe. I to nic, że implementacja jest dostępna. Nie zapominaj, że zaczęło się od mniejszego WROVER-a, który miał 4MB pamięci a nie 16 jak obecnie.
24. • 24:
       
      CommentAuthorpirx
    • CommentTime23 Mar 2024 22:03

     
    ->link<-
25. • 25:
       
      CommentAuthorPeri Noid
    • CommentTime23 Mar 2024 22:03

     
    Zaczyna się robić ciekawie...
26. • 26:
       
      CommentAuthorMq
    • CommentTime23 Mar 2024 23:03

     
    @pirx: ja rozumiem, że po Waszej stronie kałuży - jak to fajnie określiłeś - może to chodzi i dobrze, nie natknąłeś się na problemy. No ale u nas jest z tym syf i to dotyczy większej ilości ludzi. Nikt współcześnie nie posługuje się starymi protokołami mając dostępne lepsze, więc nie rozumiem dlaczego autor rozwiązania wybrał takie jak wybrał i zaparł się na zasadzie napisz.se bo jest opensource. To nie działa. Jak ktoś słusznie zauważył były już o tym dyskusje ze 3 lata temu i i tak nikt tego nie tyka. Autorzy wrzucają natomiast często info motywujące do tworzenia nowego softu na Atari, które będzie korzystać z Fujineta. Ja bym się tym np. zainteresował i propagował Fujinet zarówno w swoich grach, jak i w tych które wydaję. Na początku jak pokazał się Fujinet, to bardzo dopingowałem rozwój i jarałem się tym, że to będzie jakaś nowa przyszłość. Ale ponieważ mi Fujinet nie działa, to dawno temu to olałem i tyle. Teraz dotarł do tego samego punktu gorgh jak widać. Ciekawe jak wielu jeszcze innych programistów doszło do tego miejsca i tutaj zakończyło przygodę. Mi po prostu jest szkoda tego rozwiązania, bo mogło być fajne, a tak, to odpowiedzcie sobie sami dlaczego (między innymi) nie powstało za dużo softu na Atari korzystającego z Fujinet.
27. • 27: CommentAuthorpin
    • CommentTime23 Mar 2024 23:03

     
    ... dlatego też od dawna twierdzę, że z tym UDP to FN nadaje się co najwyżej do pogodynki i statystyk covidowych ;) Już na samym początku mając FN robiłem test z uploadem na serwer Bociana tak +- 4MB danych i było przy tym minimum kilkanaście błędów. Net - światłowód.
28. • 28:
       
      CommentAuthorpirx
    • CommentTime24 Mar 2024 00:03 zmieniony

     
    > Cześć... Mam taki problem - mam taki post jak poniżej, który był napisany ewidentnie w momencie niepotrzebnego wzburzenia. Czy mogłabyś przepisać go tak, żeby nie był taki agresywny?
    
    > ChatGPT
    Rozumiem, chcesz, aby przekaz był bardziej konstruktywny i pozbawiony agresji. Oto nowa wersja:
    
    "To tylko pokazuje, że istnieją pewne wyzwania związane z jakością sieci w Polsce. Nie doświadczyłem problemów z przesyłaniem danych, które mogą wynikać z pojedynczego, niesprawnie działającego urządzenia w sieci. Rozumiem, że nie każdy element infrastruktury będzie idealny, ale zastanawiam się, jak możemy poprawić stabilność połączenia, nie polegając wyłącznie na mechanizmach TCP, które skupiają próby ponowne w jednym miejscu sieci.
    
    @Mq, Twoja wzmianka o Fujinet początkowo mnie zaskoczyła, ale szybko doszedłem do wniosku, że to jedna z najlepszych rzeczy, jakie przytrafiły się Atari od 1979 roku. Technologie takie jak VBXE, Rapidus, U1MB i Stereo są świetne, ale Fujinet to coś, co wyróżnia się na tle innych, głównie dzięki pracy Thoma.
    
    Od początku słyszałem różne opinie na temat Fujinet, od wolnego SIO, przez długie wczytywanie menu, do problemów z TNFS i niektórymi grami. Zastanawiam się, dlaczego nie pojawiła się jeszcze wersja Fujinet z cartridge, która mogłaby poprawić szybkość działania. Menu, mimo że zostało zoptymalizowane przez Kubę Husaka, mogłoby być jeszcze bardziej intuicyjne i szybsze. Co więcej, rozumiem, że poprawa niektórych aspektów może zająć więcej czasu i wysiłku, ale warto byłoby skupić się na tych kwestiach.
    
    Wydaje mi się, że problem z ładowaniem niektórych gier wynika z niekompatybilności loadera, co również mogłoby być obszarem do poprawy.
    
    Mimo wszystko, uważam, że Fujinet ma ogromny potencjał do bycia jeszcze lepszym. Wiem, że wszyscy jesteśmy zajęci, ale warto zgłaszać uwagi i pomysły na poprawę. To ważne, aby społeczność miała możliwość dzielenia się opiniami i współpracowania nad rozwiązywaniem problemów.
    
    Zachęcam do dzielenia się swoimi doświadczeniami i propozycjami. Razem możemy sprawić, że Fujinet stanie się jeszcze lepszym narzędziem dla społeczności Atari."
    
    link do zgłaszania problemów: ->link<-
29. • 29:
       
      CommentAuthorMq
    • CommentTime24 Mar 2024 01:03

     

    pirx:

    @Mq - powiem Ci, że to "gówno" o którym napisałeś lekko mnie zdederwowało, na szczęście równie szybko mi przeszło.
    

    
    
    @pirx: ja Ciebie nie chciałem zdenerwować. Mam swoje specyficzne poczucie humoru, a gówno w nim się dobrze sprawdza do różnych porównań:-) Nie jest tak, że fujineta określam mianem gówna. Urządzenie jest super, tylko niedorobione, niedokończone, nieprzemyślane. Porwali się chłopaki na coś, uparli się przy czymś, zrobili nie tak jak trzeba. Ja to widzę tak. Ale jak na uwagi dostaje się odpowiedź, że nikt tego nie będzie robił, że napisz.se i że jest opensource, no to niech będzie.
    Szczerze mówiąc, to ja tu się śmieję jak to wszystko piszę, bo z jednej strony to hobby, z drugiej bezsilność, a do tego przyzwyczaiłem się już od lat, że jest jak jest i świata się nie zmieni, więc niepotrzebnie w tym wątku tego kotleta w sumie odgrzewamy:-)
    
    

    pirx:

    w skrócie to uważam, że fujinet to najlepsze, co się atarce przytrafiło od 1979 roku.
    

    
    
    @pirx, może Cię zaskoczę, ale ja też tak uważałem w momencie jak się to pojawiło. I nadal uważam, że to jest zajebisty pomysł. Bawił bym się tym gdyby działało. No ale jak nie działa, to czar niestety prysł.
    
    Mamy Fujineta, ale pomyślcie sami: dlaczego nie ma żadnych zajebistych gier sieciowych na niego, choć minęło już kilka lat? Dlaczego nie powstaje nic ponad tą symboliczną "pogodynkę"? Wg mnie właśnie coś jest na rzeczy, że po prostu się nie da. No trudno, Fujinet powoli trafia do przegródki z ciekawostkami.
    
    Co do zgłaszania, to zgłaszałem w wątku na atariage. Prosiłem, żeby dopisał ktoś kto zna się na tych protokołach w czym jest rzecz. Nawet chyba ktoś tam się udzielał oprócz mnie wtedy. Ale odpowiedź była trochę w stylu "u mnie działa", było też "napisz.se", no to odpuściłem, nie wracałem i już nie będę do tego wracał.
    
    Jak się pojawi fujinet poprawiony tak, że będzie działał po TCP, to będę się nim bawił. Jak będzie chodził stabilnie na dowolnym połączeniu internetowym, to może zrobię pod niego jakąś grę nawet i będę implementował chętnie w grach jakieś funkcje z nim związane. Jak nie, to nie. Trudno.
    
    Aha, żeby nie było: od czasu do czasu aktualizuję sobie firmware w swoim fujinecie. Od czasu do czasu odpalam go też i łączę się z jakimś serwerem. Czasami odpalam sobie serwer w sieci lokalnej i z nim się łączę i coś tam odpalam. No i myślę sobie jakie to zajebiste by mogło być i jak niesamowicie jest gdy Atari łączy się przez WiFi. Mam kupę radochy przez 5-10 minut, po czym fujinet wraca do szuflady:-) Fajnie że mam fujineta:-)
30. • 30:
       
      CommentAuthorgienekp
    • CommentTime24 Mar 2024 09:03

     
    A próbowaliście eksperymenty z OpenVPN? Ja nie mam FujiNETa (czyli się wypowiem) ale bawiłem się IoT z naszymi sieciami komórkowymi i generalnie to tak działa, że nie działa. I dokładnie takie same problemy jak opisujecie. Pakiety latają nie wiadomo gdzie i w jakiej kolejności. Może jak się napisze super server-client z buforami to zadziała, ale proste kody się wieszają i trzeba łapać na timeoutach.
    
    Ale zrobiłem sobie tak że jest:
    cudak<->(WiFi<->router<->OpenVPN)<->LTE<-WORLD->FTH<->(router_PublicIP<->OpenVPN<->(*))
    
    (*) to znaczy, że wchodzi z tunelu i wraca w świat światłem.
    
    Okazało się, że ten router z OpenVPN (tcp) pakując cały ruch w tunel jakoś to lepiej ogarnia i sieć LTE tak nie fika. OpenVPN instalujemy na routerze a nie na cudaku, dlatego on nawet nie wie, że jest tunelowany.
    
    Zamiast tej końcówki z routerem z publicznym IP z ciekawości możnaby sprawdzić na darmowym NordVPN czy innym "sharku".
31. • 31:
       
      CommentAuthorjhusak
    • CommentTime24 Mar 2024 20:03

     
    A jak zrobić tak, żeby po lokalnej sieci WiFi dobrze działało?
32. • 32:
       
      CommentAuthorPeri Noid
    • CommentTime24 Mar 2024 21:03

     
    Mi działa dobrze. Może coś ci sieje? Może AP masz jakiś felerny? Albo metalowe blachy w ścianach odbijają sygnał? ;-)
33. • 33:
       
      CommentAuthorPecus
    • CommentTime24 Mar 2024 21:03 zmieniony

     
    Ale to wszystko, to jest naprawianie błędu koncepcyjnego FujiNeta!
    
    Protokół UDP z definicji nie gwarantuje prawidłowego przesłania danych. Jest to jego cechą i już. To że w dzisiejszych czasach sieci w których straty są minimalne to w zasadzie codzienność, nic tu nie zmienia.
    
    Ten protokół nie jest przeznaczony do tego i tyle (odsyłam do specyfikacji w której określone jest do czego powinien być stosowany).
    
    Szukacie dziwnych metod obejścia problemu, którego przy przemyślanym projekcie po prostu nie ma.
    
    "-Hm... Jak tu zrobić transmisję plików do Atarki?
    -Protokol UDP zapewnia szybkość bez gwarancji jakości, TCP - przeciwnie.
    -No tak potrzebujemy bezbłędnej transmisji a na szybkości nam nie zależy aż tak bardzo.... zróbmy to po UDP!"
34. • 34:
       
      CommentAuthorMq
    • CommentTime25 Mar 2024 00:03

     
    @jhusak: jak sobie odpalę serwer tnfs na komputerze w sieci lokalnej, to fujinet śmiga mi z tym serwerem bez najmniejszych problemów. Czego konkretnie dotyczy Twoje pytanie?
    
    @Pecus: dokładnie to wszystko miałem na myśli, podpisuję się pod całą Twoją wypowiedzią obiema rękami. To tak w sumie do @pirxa - żeby dobrze rozumiał co miałem na myśli i nie miał do mnie pretensji o sposób wypowiedzi:-)
35. • 35:
       
      CommentAuthorpirx
    • CommentTime25 Mar 2024 05:03

     
    @Pecus
    >"-Hm... Jak tu zrobić transmisję plików do Atarki?
    >-Protokol UDP zapewnia szybkość bez gwarancji jakości,
    ...
    
    to nie było tak - chłopaki coś wymyślili, wzięli co było (tnfs), zmontowali proto i to działało. od samego początku niczego nie ukrywali, cały proces (wręcz do znudzenia) opisywali, cały czaś na pełnym open source.
    ktoś sobie zmontował fujineta na breadboardzie, potem zaprojektowali referencyjną płytkę i ludzie (inni) zaczęli to produkować dla lutownicosceptycznych jak ja.
    dlaczego, bo to cały czas działo.
    ok, rozumiem, w europie centralnej nie działa. no i Jan Krupa (chyba nie amerykanin) to poprawia wreszcie.
    
    @Mq - nie ma gier. no jest jedna ładna giera (pokerek taki), miałem taką fazę, że co wieczór wchodziłem na ten ich system do gierek, nawet ze 2 razy zagrałem z człowiekiem (tak to tylko boty i boty).
    Thom aż do znudzenia pisze wszędzie, gdzie się da jak robić giery (btw - jego urządzenie N: działa normalnie to tcp/ip), ale wysypu specjalnego nie ma.
    ja bym bardzo chciał zrobić skorcza na fujineta, i może się to uda, tylko niestety trzeba mieć z tyłu głowy, że pewnie nikt w to nie będzie grał, bo ilu 50+ latków ma czas, żeby gierki odpalać i to nie te, w które grał w dzieciństwie.
    
    Myślę, ze dlatego Thom zaczął krucjatę w celu dodawania high-score do starych gier ->link<-
36. • 36:
       
      CommentAuthorjhusak
    • CommentTime25 Mar 2024 08:03 zmieniony

     
    U mnie nie działa, to znaczy:
    Z reguły działa - koduję coś na macbooku, w tle tnfs, kompiluję program, tworzy się xex zamontowany jednocześnie pod fujinet.
    Wtedy option - reset w kompie i odpalam program.
    I często się wczytuje po 5-10 razy z rzędu, a potem dupa. stop. kilka sektorów i stop. Timeout. Reboot - to samo. Przestawianie drzwi - pomaga na chwilę albo i nie (drzwi metalowe) No i wtedy przechodzę na starą dobrą kartę SD i odpalam z niej, bo nie mam siły psychicznej.
    
    Routery tplink, 2 (po jednym na piętro), w okolicy jakieś resztki sygnałów routerów sąsiadów. Odległość komp-router - 2m. Atari - router 1.5m.
    
    Router mam ustawiony na 2.4 i 5GHz jednocześnie.
37. • 37:
       
      CommentAuthorPecus
    • CommentTime25 Mar 2024 09:03 zmieniony

     
    @pirx: No ja wiem, że nie było tak jak napisałem. Ironizowałem :)
    
    Chłopaki wzięli gotowca ze Spectruma (trochę inna platforma sprzętowa ale kod wspólny), dłubnęli trochę kodu do komunikacji po SIO i nie starczyło umiejętności/zapału/nie mieli potrzeby na więcej.
    I nie umniejszam im w niczym, nawet czuję ten wysiłek, kiedy chcesz dopisać kawałek kodu, a robisz to pierwszy raz w tym języku, ucząc się go jednocześnie - a tak być może było, a może nie. Nie wiem.
    
    Finalnie zadziałało i spełniło oczekiwania twórców.
    Sam bym tak robił :)
    
    I nie deprecjonuj mi tu jakości sieci w Polsce :)
    Pamiętaj że istnieje coś takiego w każdej sieci jak akceptowalna stopa błędów, jak gdzieś u Ciebie się coś wysypie a operator uzna, że taka stopa błędów jest akceptowalna (bo w zasadzie nie ma wpływu na jakość ruchu. TCP sobie radzi :) ) - nie naprawiamy od razu, to sam doświadczysz.
    
    Teraz masz po prostu szczęście być blisko serwerów.
    A jak bym odpalił jutro taki u siebie? Też mam dobre łącza, ale to jednak kawał drogi.
38. • 38:
       
      CommentAuthorAlex
    • CommentTime25 Mar 2024 11:03

     
    Czyli wygląda na to, że trzeba cał firmware napisać od nowa, by działał porządnie przez TCP. Ehh...
39. • 39:
       
      CommentAuthorpirx
    • CommentTime25 Mar 2024 12:03 zmieniony

     
    @Alex nieprawda, wyżej dałem linka do commita, który dodaje protokół ftp i smb. i to nie chodzi o "cały firmware", tylko klienta tnfs, czyli metodę czytania ze zdalnych serwerków.
40. • 40:
       
      CommentAuthorPecus
    • CommentTime25 Mar 2024 12:03 zmieniony

     
    Dokładnie tak.
    TCP już jest obsługiwane, ale cała obsługa plików z serwerów zdalnych leci TNFSem, i pewnie jest zaszyte to dość głęboko, bo optymalnie byłoby to teraz zmienić na klasyczny FTP i nie potrzeba by było specjalnego serwera, a problemy z transmisją przestały by tego dotyczyć.
41. • 41:
       
      CommentAuthorjhusak
    • CommentTime25 Mar 2024 14:03 zmieniony

     
    A jest jeszcze tftp :)
    
    
    A te serwery zdalne to mogiła, bo tyle ich jest, trzeba wszędzie zmieniać!!! I tak przez błąd projektowy wiele osób ma więcej roboty.
42. • 42:
       
      CommentAuthorAlex
    • CommentTime25 Mar 2024 14:03

     
    No dobra, to dwie rzeczy:
    1) Gdzie jest link do firmwareu, o którym pisze Pirx, czyli z obsługą SMB i FTP?
    2) Czy da się ten TNFS przerobić z UDP na TCP?
43. • 43:
       
      CommentAuthorPecus
    • CommentTime25 Mar 2024 14:03

     
    Ad. 2
    Nie ma potrzeby (wg mnie). Bo to serwer nie obsługuje ruchu po TCP, więc trzeba by najpierw dłubnąć w oprogramowaniu serwera, by potem znowu grzebać w samy FN.
    Łatwiej (choć obawiam się, że nie tak łatwo ze względu na mocne scalenie tego z menu wyboru plików itp.) zastąpić po stronie FN odwoływanie się do serwera TNFS odwoływaniem się do serwera FTP.
    
    A wtedy jednym ruchem pozbywamy się TNFS i UDP.
    
    Wada - zamiast serwerów TNFS trzeba by postawić serwery FTP - ale czy to wada?
44. • 44:
       
      CommentAuthorjhusak
    • CommentTime25 Mar 2024 14:03

     
    Jest jeszcze opcja taka, że fujinet wie, jakim protokołem gada z serwerem. Wpisując ip serwera można też podać typ. I wtedy wilk syty i big city.
45. • 45:
       
      CommentAuthorAlex
    • CommentTime25 Mar 2024 14:03

     
    FTP jest bardziej uniwersalny i raczej każdy NAS ma go w standardzie :)
46. • 46:
       
      CommentAuthorPeri Noid
    • CommentTime25 Mar 2024 14:03 zmieniony

     
    @Alex: teoretycznie TNFS powinien działać po TCP ale dostępny serwer ma ten protokół niezaimplementowany (odbiera połączenia ale nie realizuje żądań bo funkcje są puste w kodzie). Wystarczyłoby to uzupełnić i po sprawie - przynajmniej jeśli chodzi o serwer.
    
    @Pecus: O tyle wada, że FTP jest uznany za podatny na ataki i nie bez powodu przeglądarki mają już protokół FTP wycięty - Nowy Chrome czy Firefox po FTP już nie chce gadać.
47. • 47:
       
      CommentAuthorAlex
    • CommentTime25 Mar 2024 17:03

     
    @Peri Noid - Oooo i widzisz - to już coś :)
48. • 48: CommentAuthornewton
    • CommentTime3 Apr 2024 22:04

     
    Stworzyłem dwa PR-y do repo Fujinet:
    
    ->link<- - dodaje support dla TCP w tnfsd
    ->link<- - dodaje support w Pythonowym kliencie (przydatne do testów)
    
    Jeśli wszystko pójdzie dobrze, to kolejna kontrybucja będzie do ->link<- aby wspierać nowy protokół także w firmware.
49. • 49:
       
      CommentAuthorjhusak
    • CommentTime3 Apr 2024 22:04

     
    BBBBRRRAAAWWWOOO!!!!!
    Jeśli to się przyjmie, to będzie wielki GIT!
50. • 50:
       
      CommentAuthorMq
    • CommentTime4 Apr 2024 11:04

     
    Świetne wieści! Trzymam kciuki, żeby się udało to wrzucić w oficjalny firmware i żeby wreszcie Fujinet działał tak jak się należy temu świetnemu urządzeniu! Bardzo dobre wieści:-)