NTG ale może...

Użytkownik "jacek pozniak" snipped-for-privacy@flowservice.pl napisał w wiadomości news:593ceee9$0$5164$ snipped-for-privacy@news.neostrada.pl...

Było się z ICPNETem skumać, olali by to... Mógłbyś uruchamiać co chcesz...

Dnia Fri, 9 Jun 2017 19:38:44 +0200, sundayman napisał(a):

Jesli tylko masz publiczny IP, to do testow wystarczy, bo nawet jak sie zmienia czesto, to raczej co dzien, a nie co minute.

DynDNS tez pomoze, te darmowe to IMO nie sa zbyt pewne, ale do uruchomienia starcza.

Ale roboty to cie czeka sporo, jesli to przy takiej jednostronnej lacznosci ma pewnie dzialac w dluzszym okresie.

J.

Lepiej chyba od razu na zewnętrznym rozwiązaniu; przećwiczysz ewentualne problemy związane z kupowaniem tego typu usług; kwestie kupić/nie_kupić domenę, etc.

jp

W dniu 09.06.2017 o 08:18, Zbych pisze:

Jeśli ma DSL to nie jest problem. Robi sobie przekierowanie na własnym routerze.

I pwenie dostaje golca na którym musi sobie postawić jakiegoś linuksa i go skonfigurować tak żeby m,u nikt się nie włamał.

W dniu 11.06.2017 o 22:06, Mario pisze:

To chyba jest normalne? Na swoim kompie będzie miał inaczej?

W dniu 09.06.2017 o 19:38, sundayman pisze:

Do testów to weź sobie darmowe konto na no-ip. Ale nie licz że to rozwiązanie na dłużej. Dyndns po zmianie właściciela zlikwidował darmowe. Tak więc nie przyzwyczajaj się. Jeśli masz router DSL o sobie ustaw sobie na nim, przekierowanie portów, kup sobie za 300 zł poleasingowego della.

sobie wszystko skonfigurujesz i potestujesz to przeniesiesz na VPS. Oczywiście lepiej gdy to działa na Linuksie, bo VPSy są z reguły linuksowe.

W dniu 11.06.2017 o 22:09, Zbych pisze:

NA swoim kompie jest pewnie za routerem z NATem i na routerze ma blokowanie portów. W VPS jest wpięty wprost w internety i musi sobie skonfigurować iptables, przemyśleć kwestię logowania zdalnego do różnych usług, napisać (znaleźć w necie) skrypty sprawdzające ataki itp.

W dniu 11.06.2017 o 22:20, Mario pisze:

Przesadzasz. Serwerowe wersje instalatorów nie wystawią mu na świat nic poza ssh, więc na dzień dobry nic nie trzeba blokować.

Obecnie to działa tak ;

- urządzenie ma modem GPRS z kartą telemetryczną. Moim zdaniem ona ma publiczny adres (oczywiście nie stały). Pewności nie mam, ale gdyby nie miała, to chyba by to wszystko nie działało, jak działa.

- modem łączy się z serwerem, który robi za ""pośrednika" w dwie strony. Od strony PC jest sterownik, który udostępnia wirtualny RS. Jak on się dokładnie łączy, tego nie wiadomo, bo po prostu jest w ustawieniach opcja "cloud" - coś jak w kamerach IP. I od strony serwera jest ten modem "widoczny online" (mam konto na tym serwerze i można to podejrzeć po prostu przez stronę).

I to jest jakby "przezroczyste" łącze RS232. Czyli komunikacja odbywa się po tym wirtualnym RS. Ilość danych przesyłanych jest symboliczna - w dodatku nie non stop, a tylko na życzenie operatora - z poziomu programu na PC obsługiwanego przez użyszkodnika.

To, co ewentualnie by mnie urządzało, to takie samo rozwiązanie, tylko na własnym serwerze (w sensie - moim, niekoniecznie na moim biurku). Dlaczego ? Ano, ponieważ chiński serwer lubi sobie padać w chwilach dowolnie wybranych. A to jest kłopot.

No a wersja rozszerzona - to właśnie np. taki thingsboard, gdzie user może sobie podejrzeć stan urządzenia lub coś w nim przestawić z poziomu www.

Oczywiście pisząc "serwer" mam na myśli serwer udostępniony przez producenta modemów. Czyli jest tak:

MODEM ---internet(serwer producenta) --- komputer PC użytkownika

No i na komputerze użyszkodnika odpowiedni program , który via ten RS232 się komunikuje z urządzeniem podłączonym do modemu. Proste jak idea cepa.

Rzecz jasna platforma typu thingsboard.io jest lepszym rozwiązaniem na przyszłość - dlatego m.in. muszę z tym powalczyć.

Dnia Mon, 12 Jun 2017 01:15:51 +0200, sundayman napisał(a):

Raczej nie ma - sieci GSM z reguly ukrywaja.

No wlasnie - modem sie laczy, i mu ukrywanie nie przeszkadza.

Przez tenze serwer zapewne.

Oprogramowanie serwera dosc specyficzne i trzeba by napisac/zaadoptowac, a jeszcze zmienic w modemie adres serwera z ktorym sie laczy.

J.

No ok. A mnie to w czym przeszkadza taka sytuacja ? Raz na jakiś czas urządzenie poprosi modem o wysłanie lub odebranie danych.

Ale nie ma z tym akurat problemu. W modemie można ustawić jeden z 3 trybów;

1. TCP/UDP
2. TCP/UDP z włączoną opcją CLOUD (wtedy via serwer producenta)
3. HTTPD (GET/POST)

Oczywiście można sobie dowolnie wybrać IP i port.

Można oczywiście jeszcze via SMS, z tego korzystałem na samym wstępie. Fajne, ale do dupy :)

To jak najbardziej - większość hostingów oferuje php i mysqla, tu już da się zrobić zapis. Byle dało się z urządzenia gadać po http 1.1.

Bardziej precyzyjnie - stały/publiczny IP zapewnia hosting.

Pytanie co dokładnie i w jakiej ilości zapisujesz, względnie co potem z tym robisz.

Jak chcesz to możemy coś takiego zestawić, VPS-a póki co mam :)

Mamy teraz 20 (do testów) + kilkaset w polu, były problemy z przełączaniem operatorów, ale okazało się, że to po stronie naszego softu. Ogólnie ten Play działa stabilnie (jak na GPRS...) tylko są lokalizacje, gdzie trzeba wymusić wybór konkretnego operatora, bo automatyczny wybór zrywa.

Korzystamy tylko z 2G.

Nie ma - i dlatego aktywny FTP mi nie działał. Swoją drogą aktywny FTP (gdzie klient otwiera port, a serwer próbuje się z nim połączyć) to wg mnie jakaś pomyłka... z kolei nasze funkcje do pasywnego FTP-a na jednym z operatorów (chyba Plusie - tzn. Playmetric ustawiony na Plusa) zachowywały się niestabilnie (tak jakby z punktu widzenia klienta sesja kontrolna umierała podczas transferu), ale ustaliliśmy że to bug u nas (nie mam dostępu do źródeł tych konkretnych funkcji, ale przejrzałem tcpdumpa) a nie u operatora. Po zastąpieniu tej implementacji inną problem zniknął i chodzi stabilnie na każdym operatorze.

Hmm, czyli modemy są połączone z serwerem cały czas i operator na PC wymusza transfer danych? Ile masz tych urządzeń? Jak 100 to jeszcze się da, ale jak np. 10000, to może być problem...

Mieliśmy 300 urządzeń, które łączyły się o tej samej godzinie do serwera i wymieniał dane. Zarzynało to i serwer i łącze, musieliśmy wprowadzić losowanie czasu połączenia.

Ogólnie w takich rozwiązaniach raczej unika się połączenia aktywnego non-stop, o ile to tylko możliwe, i robi się heartbeaty, wysyłane przez klienta (czyli klient łączy się, pyta serwera czy coś dla niego ma, i wtedy następuje wymiana danych).

Pod warunkiem że modem będzie utrzymywał połączenie z serwerem. Takie utrzymanie połączenia, w przypadku tysięcy modemów, zaczyna być bolesne dla sieci. Najlepiej jakbyś ustalił z Playem, czy dadzą radę utrzymywać po jednym połączeniu z X urządzeń rozsianych na obszarze Y...

Teraz kwestia protokołu - jest znany? Bo może to jakiś zamknięty protokół producenta?

Co do IP i portu - w HTTP/1.1 musisz podać jeszcze nazwę hosta. Bez niej żaden dzielony hosting nie zadziała, bo tam jest wiele hostów na jednym IP i w nagłówku Host: przychodzi nazwa. VPS oczywiście zadziała, bo to będzie Twój serwer i nie musisz tam w ogóle konfigurować vhostów.

Jeśli mam strony, przykładowo:

test.abc.pl

To one wszystkie mogą być na tym samym adresie IP. Klient łączy się z tym IP na porcie 80 (http) lub 443 (https) i wysyła w żądaniu np.:

GET / HTTP/1.1 Host:

Wtedy serwer wie, że żądanie jest do adresu (vhosta - wirtualnego hosta)

Co potem gada do tego RS-a? Twoja aplikacja? Bo jeśli tak, to może w ogóle pominąć tego "wirtualnego RS-a" i zrobić aplikację, która zamiast po RS-ie komunikuje się przez TCP lub web (zwykłym request/response lub poprzez websockety)?

I zje kosztowo :)

A gdybyś chciał zrezygnować z softu producenta, to ten modem ma zaimplementowany jakiś (prosty) stos TCP/IP i polecenia AT do tworzenia połączeń (TCP) lub wymiany datagramów (UDP)? Czy musisz mieć własny stos TCP/IP?

Hmm, czyli tak naprawdę główną zaletą tego modemu jest przezroczysty sieciowo RS-232, który jest w pakiecie z serwerem producenta, tak?

No to teraz pytanie, czy protokół producenta jest znany lub czy możesz otrzymać od producenta pliki serwera do postawienia u siebie, tak żebyś nie był zależny od chińskiego, padającego serwera...

VPN to taki LAN, tylko że przez Internet :) Tworzy Ci się po prostu dodatkowe urządzenie sieciowe, któremu przypisujesz adresy i które komunikują się tak, jakbyś miał komputery spięte LAN-em.

Przynajmniej w przypadku urządzenia TAP (Network Tap) tak jest, bo jest jeszcze opcja TUN (Tunnel), która działa warstwę wyżej (na warstwie IP). Dopóki nie robisz cudów typu bridging z innymi interfejsami lub transfer innych protokołów (poza IP) to nie ma to znaczenia :)