jakby działało lepiej, to wystarczy postawić na tym samym kompie serwer tnfs, do którego wchodzi się lokalnie. na razie trzbeba by pliki przeglądać i ściągać ręcznie z poziomu tnfs_client.py, to co chciałem dorobić, to automatyczny ściągator :]
Paweł, ale to próba protezy, a nie rozwiązanie. Zastanawiam się skąd pomysł na TNFS w FN, skoro implementacja zwykłego FTP byłaby równie nieskomplikowana na tej platformie sprzętowej. W przypadku specraneta może miało to sens, bo tam więcej jest obsługiwane po stronie samego spectruma i maksymalne uproszczenie protokołu ułatwia działanie całości. Ale FN - gdzie wszystko dzieje się w ESP?
No nie wiem.
Ja tam się nie znam, ale nie idzmy w tę stronę. Protezowanie w ten sposób jest słabe (nie samo tworzenie protezy, a raczej to, że jest to konieczne). Ja wiem, że na tym etapie projektu powiedzenie głośno: "Chłopaki, TNFS był błędem, może zmieńmy to na klasyczny FTP", to troche wywraca projekt. Ale jeśli (bo nie wiem tego na pewno, choć wszystkie znaki na to wskazują) to TNFS jest tutaj problemem, to może jednak warto...
Tak jak pisałem, piszę to z punktu widzenia obserwatora, więc proszę znowu nie zarzucać mi bezpodstawnej i niepotrzebnej krytyki :P
Na własne potrzeby obstawiałem, że chodzi o obciążenie sprzętu stosem TCP. Z drugiej strony ten stos zapewne tam już jest... No to może kwestia poziomu komplikacji samego protokołu tnfs?
tak dla jasności - nie chodziło mi o to, żeby tnfs działał lepiej, bo osobiście nigdy nie miałem problemów - raczej chodziło mi o zrobienie czegoś w rodzaju archiwum różnych serwerów tnfs i łatwego w dostępie huba - jeden adres, wszystkie zasoby. ew. poprawa łączności po UDP to tylko (możliwy) efekt uboczny.
Ale jeszcze większy sens miałoby postawienie takiego huba na serwerze widocznym ze świata dla wszystkich. I wtedy znowu pojawią się problemy sieciowe.
Tak sobie pomyślałem, że stawianie w sieci lokalnej kolejnego serwera (TNFS) kiedy pewnie połowa userów ma jakiegoś NASa na którym i tak działa lokalny FTP (albo jednym kliknięciem działać może) to też słabe rozwiązanie (wiem, że zawyżam średnią moimi NASami ;) ).
Tak więc nie mając FN :P postuluję przejście z TNFS na FTP (patrząc na implementacje obu, to poziom skomplikowania jest baaardzo podobny - tym bardziej, że dla arduino jest milion gotowców (jak to w arduino niezgodnych samych ze sobą :) :) )).
A HUB.... czy to TNFS czy FTP mógłby działać tak samo.
Pecuś - lokalnie TNFS działa bardzo dobrze, zarówno pod kontrolą Windows jak i Linux. W przypadku tego pierwszego systemu instalacja ogranicza się praktycznie do umieszczenia skrótu w autostarcie. Monsoft udostępnił na githubie wariant pod NAS'y - nie miałem niestety czasu jeszcze się nim zająć. Wiem, że pojawił się port Fujinet pod Linux... w wolnej chwili pobawię się nim i zobaczę czy też miewa takie bolączki na łączach mobilnych...
piguła - ale zdaję sobie sprawę. Tylko ciągle nie rozumiem po co ten TNFS skoro w przypadku ESP32 FTP jest w zasadzie dostępny od ręki. Bibliotek od pyty, a cała taka biblioteka to raptem kilobajt (tekstu) - mam wrażenie że jak się poprzyglądam, to okaże się, że obsługa TNFSa w FN jest dłuższa niż byłby FTP :). Wydaje mi się, że to pozostałość po wzorowaniu się na spectranecie. Tyle że on nie jest na ESP32 (który kawał obsługi TCP ma z definicji) i (Tak jak pisałem) tam więcej jest robione przez samo spectrum, więc uproszczony protokół pewnie był koniecznością i musiał powstać ten nieszczęsny TNFS.
Słuchajcie, a czy aby na pewno nie jest to kwestia ustawienia jakichś parametrów, nie wiem jakichś timeoutów albo czegoś tam innego na tych serwerach sieciowych TNFS?
Ja rozumiem, że łącze mobilne u mnie może mieć problemy. Ale dlaczego w takim razie po tym moim łączu (cały czas tym samym) cały czas poprawnie działa mi połączenie z serwerem: atari-apps.irata.online i na tym powyższym serwerze od kilku dni jak to intensywnie testuję, _ANI_RAZU_ nie miałem problemu i ani jednego takiego przypadku, żebym się z nim nie mógł połączyć, albo z niego czegoś uruchomić, skopiować czy cokolwiek bądź.
Natomiast cały czas mam powtarzalne w kółko te opisane wcześniej problemy, próbując łączyć się z serwerami: FujiNet.online FujiNet.pl
Nie mam też żadnych problemów z połączeniem z serwerem w sieci lokalnej odpalonym na windowsie. Oczywiście wiem, że to bez związku jeśli rozmawiamy o tym, że problemem ma być łącze internetowe, ale wspominam o tym, żeby było wiadomo, że sam mój FujiNET działa poprawnie i sieć lokalna WiFi też poprawnie w tym zakresie działa.
@Mq: w samych ustawieniach tnfs nie da sie nic pogrzebać, bez grzebania w żródłach. konfiguracja jest szczątkowa. Może to bardziej ustawienia jakiegoś routera NAT? Albo inna wersja samego serwera?
Ja mam fujinet.pl kompilowany z najnowszego mastera na gitlabie, stąd: ->link<-
A da się jakoś z zewnątrz sprawdzić jaka jest wersja danego serwera? Ciekawi mnie czy jest jakaś różnica między serwerami, może nowsza wersja serwera coś popsuła? Z drugiej strony niby ludzie piszą, że mają podobne problemy jak ja, ale żeby ten temat miało sens badać pod tym kątem i traktować to jako jakiś punkt zaczepienia, to musiały by jakieś inne osoby jeszcze potwierdzić że mają tak samo jak ja, że ten jeden serwer im zawsze dobrze działa, a tylko te wymienione dwa pozostałe miewają problemy.
Słaby też ze mnie wyznacznik, bo ja obecne mam tylko ten jeden dostęp do internetu, który mam i nie mam gdzie łatwo sprawdzić czy moje Atari z moim FujiNET-em by działało inaczej gdzieś indziej...
Teraz pod windows świeża jest 20.1115.2 - przynajmniej jako udostępniona binarka na stronie fujineta. I ta mi lokalnie elegancko śmiga po sieci, no ale wiadomo, tu nie o lokalne problemy chodzi.
@bocianu: ja na Twoim serwerze pod warunkiem, że tam w ogóle wejdę, to mam jeszcze taki objaw, że jak sobie chodzę po katalogach, to czasem przez chwilę jest dobrze, ale co kilka przejść z katalogu do katalogu zatrzymuje mi się wszystko, totalna zwiecha tak na kilkanaście sekund i w tym czasie pali się dioda od SIO cały czas. Po tym czasie albo wchodzi do katalogu, tylko pokazuje, że jest pusty i trzeba wyjść i wejść znowu, albo wyświetla czasem jakieś śmieci w katalogu, albo w ogóle się rozłącza.
Ogólnie z tych dwóch wymienionych serwerów niestety nie da się u mnie korzystać, ale ciągle powtarzam, że ten trzeci działa mi cały czas bez problemu.
UDP czyli TNFS - i nie mam więcej pytań :) Jakiś rok temu robiliśmy w firmie testy transmisji na łączach GSM. I proste narzędzie analizujące ruch pakietów TCP i ilość powtórek pakietów wskazywało że na kablu to są pojedyncze powtórki na minutę, a po GSM liczyło się w setkach (przy założonej prędkości transmisji, stąd jako parametr - ilość powtórzonych pakietów w czasie). A UDP nie powtarza tylko raportuje błąd.
Założyłem wątek na atariage dotyczący problemów z TNFS i UDP opisywanych tu przez dwie ostatnie strony postów.
Nie jestem specjalistą od sieci i protokołów, nie jestem też jakiś super biegły w angielskim, więc opisałem to tam na tyle na ile umiałem. Jak ktoś chce pomóc w rozmowach, to zapraszam.
Najbardziej oczekiwał bym, że znajdzie się grupa ludzi potwierdzających problem również za granicą i pokaże się jakieś światełko w tunelu na przyszłe lepsze rozwiązania w FujiNET. Niemniej jednak zdaję sobie sprawę, że nikt z dnia na dzień pewnie nie powie tam że faktycznie mam rację i trzeba to natychmiast poprawić, a na kolejny dzień wypuści nowy soft:-), więc oczekuję, że chociaż wypowiedzą się tam na ten temat i wyjaśnią coś albo zaproponują jakieś rozwiązania pośrednie na przyszłość, żeby w ogóle było wiadomo jakie są możliwości techniczne i czy jest nadzieja, że komuś będzie się chciało nad tym problemem choć trochę pochylić.
Jeśli ktoś ma chęć śledzić co tam się pojawi w odpowiedziach, lub pomóc w dyskusji gdyby się ona jakoś korzystnie rozwinęła, to zapraszam, może przyniesie to jakieś pozytywne skutki.
Jeśli ktoś ma pytania o Fujinet - to właśnie na naszym zoomie pojawił się Thomas Cherryhomes (jeden z głównym developerów Fujinet) i można zadać mu pytania.
Dzięki. Do tej pory informacje o każdej aktualizacji były w tym wątku: ->link<- Od godziny szukam co się zmieniło w kolejnych aktualizacjach i nigdzie nie mogę znaleźć informacji.
Atari is _very_ stable at this point, so yes, I've been concentrating on facilitating platform bring-ups for close to half a dozen platforms in parallel.
These include
* Apple II * Apple Macintosh (128K/512K/Plus/SE/etc.) * Commodore * TRS-80 Color Computer * RC2014
and others.
I have also been circling around doing much needed updates for the Coleco Adam version.
I must also ask, now that the platform is stable, that people start doing things with it, and based on what people do, we will adapt the platform and infrastructure to accomodate. :)