Dotaz: TCP spojeni klienta se serverem

[petrfm]

Ahoj, experimentuju s pripojenim embedded desky k serveru s linuxem. Potreboval bych navazat spojeni s linuxovym serverem - zrejme TCP s dlouhym timeoutem - aby to viselo na lince a jednou za cas spolu zakomunikovalo. V pripade vypadku spojeni by ta se ta deska znovu pokousela spojit a odeslat data z bufferu.

Na serveru s linuxem bych potreboval prichozi data zpracovat skriptem a ukladat do databaze no a naopak, data z databaze zase odesilat na to zarizeni. Jake reseni doporucujete na serverove strane?

1) Neni nekde nejaky tutorial na tohle tema? S Cckem si moc netykam, existuje neco hotoveho, co by dokazalo treba pracovat se souborem, ktery si budu pomoci PHP skriptu vybirat, parsovat a ukladat do databaze / vkladat do nej data k odeslani?

2) Da se to TCP spojeni smerovat primo na php script, nebo na tohle neni PHPcko vhodne?

3) Tech zarizeni by melo byt na jeden port pripojenych nekolik - to by ale TCP melo osetrovat samo a vytvaret pro kazde spojeni extra socket, ze ? Cili kazde zarizeni by komunikovalo "se svoji instanci" i kdyz to bude na jednom portu toho serveru, je to tak?

Odpovědi

[petrfm]

Jinak bylo mi tady uz porazeno pouzit netcat. Koukam na nej a mozna by se pro ten ucel vyborne hodil. Mohl by prijimat spojeni a vytvaret soubory, s cislem klienta a id zpravy, ktere by pak mohlo PHP vyzvedavat a parsovat.

1) Zajimalo by mne ale, jak to funguje, kdyz pouziju netcat v modu listen, na urcitem portu a pripoji se vice zarizeni na ten dany port. Musim mit pro kazde spustenou jednu instanci netcatu, nebo jak to funguje?

2) jak nastavit timout toho spojeni? Abych se mohl pripojit, poslat AHOJ a cekat na data od netcatu treba 5 minut? Ta zarizeni jsou totiz za neverejnou IP a casto za NATem a tak potrebuju, aby to spojeni iniciovalo dane zarizeni, ale pritom aby trvale ocekavalo zpravu od serveru a bylo schopne ihned odpovedet - ohlasit svuj aktualni stav.

[NN]

Asi by bylo vhodnejsi napsat si vlastni server, napriklad v Pythonu.

[petrfm]

Aha, tzn. ze bude bezet jako daemon a muze naslouchat na tcp portu a primo obsluhovat to spojeni i databazi, ze? Tzn. primo jak mu to bude prichazet, muze ladovat data do databaze a naopak, jakmile najde polozku v BD k odeslani, tak odpovi.

Predpokladam, ze na netu budou nejake tutorialy.

Jinak s tim PHP by se to dalo udelat taky? Jde mi o to, to nejak zatim rozhybat a pak teprve vylepsit. A php je mi prece jen blizsi, nez python. I kdyz, byla by to aspon sance se jej naucit

[GeorgeWH]

este tu chyba jedna podstatne vec - co je to za klienta? ak to vie http, nestacil by obycajny php skript? nebol by problem s identifikaciou klienta, prijimanim a posielanim dat...

[petrfm]

Prave, ze to HTTP i GET a POST docela dobre umi. Puvodne jsem zamyslel, postavit to tak, ze by se kazdych x sekund delal get na PHP script a ten by generoval odpovedi. Libi se mi to i co se tyka osetreni chybovych stavu, moznosti jednoduse presmerovat server jinam, v pripade vypadku / udrzby, apod. no a v neposledni rade taky proto, ze 80tku port maji povolenou temer vsude, cili by odpadaly problemy s firewally na nejake exoticke porty.

Vsechno by to bylo krasne, kdyby to zarizeni komunikovalo jen smerem KLIENT - SERVER. Jenomze ja potrebuju co nejrychlejsi reakci v pripade, ze server potrebuje klientovi neco rict. A tady jsem si rekl, ze to je pekna prasarna, mit v siti zarizeni, ktere kazde 3 sekundy delat GET na nejaky webserver, ze mnohem cistejsi reseni bude, mit otevreny socket a cekat na data - defakto nulovy traffic, kdyz se nic nekomunikuje.

Co si o tom myslite vy? Je to prasarna, delat kazde 3 sekundy GET, nebo resim blbosti? Resili byste to TCP spojenim, nebo se na to vykaslali a usnadnili si praci? Jde mi proste o to, ze to bude generovat neustaly traffic - sice maly, ale trvale a router bude blikat jak divy a ten server, pokud tech zarizeni bude hodne, se z toho taky pose-e.

[Jendа]

Na serveru může běžet po každém požadavku třeba minutu něco jako sleep(1); nějaký_refresh(); flush();

[petrfm]

To jako pri tom http spojeni? Tzn. ze by se nastavil apachi veeeeliky timeout a ten php script by to zdrzoval? Treba bezel v nejake smycce a kdyby prisla akce, ktera by se mela prenest na toho klienta, tak by se smycka ukoncila?

Je to ciste reseni? A nebudou to spojeni prerusovat treba routery?minuta je takova idealni doba... 60 dotazu behem hodiny se da prezit a pritom minutovy timeout neni nic tak strasneho, ze? Zvladne treba apache/nginx s php najednou takhle pridrzet stovky klientu? Kazdy http dotaz je defakto takove otevrene TCP spojeni, ze ? Jen to neobsluhuje muj server v pythonu, ale treba apache...

[Delaunay]

Pro obousměrnou komunikaci je možné použít protokol WebSocket, který využívá HTTP pro sestavení obousměrného komunikačního kanálu.

Pro PHP by se dal snad s úspěchem použít php-websocket. Jak na straně serveru, tak i na klientské straně používá PHP. Serverová strana dokáže obsluhovat více klientů zároveň.

[petrfm]

Klient bohuzel PHPcko nezvladne, tam mame jen TCPIP stack, ktery umi jen TCP spojeni klient / server a HTTP. Na klientske strane to musi byt tedy co nejjednodussi, ty vsechny ostatni ficury se budou dit na serveru, kde bude linux.

[Jary]

mužeš použít/udělat websocket-INETsocket proxy. v openstacku se např používá novncproxy co balí vnc do websocketů. Zdroj je asi https://github.com/kanaka/noVNC. I když, je tam bug způsobující zombies https://bugs.launchpad.net/nova/+bug/1048703

[Milan Uhrák]

udělal bych to přes ssh, to má vlastnost (nebo rozšíření) heartbeat, který udržuje spojeni živé.

[Michal Kubeček]

…a někdy toho umí i víc. :-)

[petrfm]

Srandicky, srandicky