Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Aplikacja webowa a urządzenie podłączone do serwera
21 views
Skip to first unread message
Grzegorz Niemirowski
May 19, 2012, 7:48:06 PM5/19/12
to
Zastanawiam si� nad aplikacj� webow�, kt�ra pozwala�aby komunikowa� si�
zdalnie z jakim� sprz�tem, konkretnie pod��czonym przez port szeregowy do
serwera WWW. Wysy�anie czego� do takiego urz�dzenia jest dosy� proste. Gdy
przyjdzie ��danie z przegl�darki, np. POST lub GET, mo�na co� wys�a� na port
szeregowy, czy to korzystaj�c z gotowych klas (PHP/ASP, zale�nie w czym jest
strona napisana), czy te� wywo�uj�c zewn�trzn� aplikacj�. Gorzej jest
natomiast w drug� stron�, bo chodzi o to, �eby to dzia�a�o w czasie
rzeczywistym. Aplikacja webowa raczej nie mo�e otworzy� sobie portu
szeregowego i czekaďż˝ aďż˝ coďż˝ dostanie.
Wi�c zostaje zewn�trzna aplikacja, kt�ra trzyma�aby otwarty port i gdy co�
dostanie np. zrzuca�aby to do pliku. Przegl�darka przez AJAX mog�aby wtedy
odpytywa� aplikacj� na serwerze (przez polling np. co sekund�), kt�ra
pobiera�aby ten plik.
Generalnie chodzi mi o co� takiego, �e jest sobie urz�dzenie z przyciskiem.
Naci�ni�cie tego przycisku powoduje wys�anie jednego bajtu przez RS-232 do
komputera na kt�rym stoi demon HTTPD. Jak to potem sensownie przes�a� do
przegl�darki, z mo�liwie ma�ym op�nieniem? Da si� to jako� lepiej rozwi�za�
ni� komunikacja przez pliki z zewn�trzn� aplikacj� odpowiedzialn� za port
szeregowy?
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 14 hours, 28 minutes and 14 seconds
zdalnie z jakim� sprz�tem, konkretnie pod��czonym przez port szeregowy do
serwera WWW. Wysy�anie czego� do takiego urz�dzenia jest dosy� proste. Gdy
przyjdzie ��danie z przegl�darki, np. POST lub GET, mo�na co� wys�a� na port
szeregowy, czy to korzystaj�c z gotowych klas (PHP/ASP, zale�nie w czym jest
strona napisana), czy te� wywo�uj�c zewn�trzn� aplikacj�. Gorzej jest
natomiast w drug� stron�, bo chodzi o to, �eby to dzia�a�o w czasie
rzeczywistym. Aplikacja webowa raczej nie mo�e otworzy� sobie portu
szeregowego i czekaďż˝ aďż˝ coďż˝ dostanie.
Wi�c zostaje zewn�trzna aplikacja, kt�ra trzyma�aby otwarty port i gdy co�
dostanie np. zrzuca�aby to do pliku. Przegl�darka przez AJAX mog�aby wtedy
odpytywa� aplikacj� na serwerze (przez polling np. co sekund�), kt�ra
pobiera�aby ten plik.
Generalnie chodzi mi o co� takiego, �e jest sobie urz�dzenie z przyciskiem.
Naci�ni�cie tego przycisku powoduje wys�anie jednego bajtu przez RS-232 do
komputera na kt�rym stoi demon HTTPD. Jak to potem sensownie przes�a� do
przegl�darki, z mo�liwie ma�ym op�nieniem? Da si� to jako� lepiej rozwi�za�
ni� komunikacja przez pliki z zewn�trzn� aplikacj� odpowiedzialn� za port
szeregowy?
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 14 hours, 28 minutes and 14 seconds
Michoo
May 19, 2012, 9:14:30 PM5/19/12
to
On 20.05.2012 01:48, Grzegorz Niemirowski wrote:
> Gorzej jest natomiast w drugą stronę, bo chodzi o
> to, żeby to działało w czasie rzeczywistym. Aplikacja webowa raczej nie
> może otworzyć sobie portu szeregowego i czekać aż coś dostanie.
Ponieważ?
Albo servlet javy na serwerze aplikacji z dodatkową klasą ładowaną w
init (tomcat/glassfish/etc), albo np aplikacja w C++ podpięta przez
fastcgi do apache.
> Generalnie chodzi mi o coś takiego, że jest sobie urządzenie z
> przyciskiem. Naciśnięcie tego przycisku powoduje wysłanie jednego bajtu
> przez RS-232 do komputera na którym stoi demon HTTPD. Jak to potem
> sensownie przesłać do przeglądarki, z możliwie małym opóźnieniem?
Ajax. Najlepiej jakiś framework który wywołania callbacków zrobi za
ciebie. Ja kiedyś używałem GWT.
> Da się
> to jakoś lepiej rozwiązać niż komunikacja przez pliki z zewnętrzną
> aplikacją odpowiedzialną za port szeregowy?
Nie napisałeś jaki system operacyjny - pod linuksem port szeregowy jest
"jakimś plikiem".
--
Pozdrawiam
Michoo
> Gorzej jest natomiast w drugą stronę, bo chodzi o
> to, żeby to działało w czasie rzeczywistym. Aplikacja webowa raczej nie
> może otworzyć sobie portu szeregowego i czekać aż coś dostanie.
Ponieważ?
Albo servlet javy na serwerze aplikacji z dodatkową klasą ładowaną w
init (tomcat/glassfish/etc), albo np aplikacja w C++ podpięta przez
fastcgi do apache.
> Generalnie chodzi mi o coś takiego, że jest sobie urządzenie z
> przyciskiem. Naciśnięcie tego przycisku powoduje wysłanie jednego bajtu
> przez RS-232 do komputera na którym stoi demon HTTPD. Jak to potem
> sensownie przesłać do przeglądarki, z możliwie małym opóźnieniem?
Ajax. Najlepiej jakiś framework który wywołania callbacków zrobi za
ciebie. Ja kiedyś używałem GWT.
> Da się
> to jakoś lepiej rozwiązać niż komunikacja przez pliki z zewnętrzną
> aplikacją odpowiedzialną za port szeregowy?
Nie napisałeś jaki system operacyjny - pod linuksem port szeregowy jest
"jakimś plikiem".
--
Pozdrawiam
Michoo
yamma
May 20, 2012, 3:00:29 AM5/20/12
to
Grzegorz Niemirowski wrote:
> Zastanawiam si� nad aplikacj� webow�, kt�ra pozwala�aby komunikowa�
> si� zdalnie z jakim� sprz�tem, konkretnie pod��czonym przez port
> szeregowy do serwera WWW. Wysy�anie czego� do takiego urz�dzenia jest
> dosy� proste. Gdy przyjdzie ��danie z przegl�darki, np. POST lub GET,
> mo�na co� wys�a� na port szeregowy, czy to korzystaj�c z gotowych
> klas (PHP/ASP, zale�nie w czym jest strona napisana), czy te�
> wywo�uj�c zewn�trzn� aplikacj�. Gorzej jest natomiast w drug� stron�,
> bo chodzi o to, �eby to dzia�a�o w czasie rzeczywistym. Aplikacja
> webowa raczej nie mo�e otworzy� sobie portu szeregowego i czeka� a�
> coďż˝ dostanie.
Serwis WCF pracuj�cy pod kontrol� windowsowego svchosta (czyli jako zwyk�a
> Zastanawiam si� nad aplikacj� webow�, kt�ra pozwala�aby komunikowa�
> si� zdalnie z jakim� sprz�tem, konkretnie pod��czonym przez port
> szeregowy do serwera WWW. Wysy�anie czego� do takiego urz�dzenia jest
> dosy� proste. Gdy przyjdzie ��danie z przegl�darki, np. POST lub GET,
> mo�na co� wys�a� na port szeregowy, czy to korzystaj�c z gotowych
> klas (PHP/ASP, zale�nie w czym jest strona napisana), czy te�
> wywo�uj�c zewn�trzn� aplikacj�. Gorzej jest natomiast w drug� stron�,
> bo chodzi o to, �eby to dzia�a�o w czasie rzeczywistym. Aplikacja
> webowa raczej nie mo�e otworzy� sobie portu szeregowego i czeka� a�
> coďż˝ dostanie.
windowsowa us�uga) + komunikuj�cy si� z nim IIS. To chyba by�oby najprostsze
rozwi�zanie pod wzgl�dem technologicznym.
yamma
Jacek Czerwinski
May 20, 2012, 3:52:17 AM5/20/12
to
W dniu 2012-05-20 09:00, yamma pisze:
protok�. Wszystko w jednej JVM, �adnych protoko��w sieciowych, dost�pne
jako struktury lokalne itd.
Dla mnie to jest najprostsze.
> Grzegorz Niemirowski wrote:
> Serwis WCF pracuj�cy pod kontrol� windowsowego svchosta (czyli jako
> zwyk�a windowsowa us�uga) + komunikuj�cy si� z nim IIS. To chyba by�oby
> najprostsze rozwi�zanie pod wzgl�dem technologicznym.
> yamma
Ja bym g�osowa� za opcj� Michoo co� w servletach i klasa realizuj�ca ten
> Serwis WCF pracuj�cy pod kontrol� windowsowego svchosta (czyli jako
> zwyk�a windowsowa us�uga) + komunikuj�cy si� z nim IIS. To chyba by�oby
> najprostsze rozwi�zanie pod wzgl�dem technologicznym.
> yamma
protok�. Wszystko w jednej JVM, �adnych protoko��w sieciowych, dost�pne
jako struktury lokalne itd.
Dla mnie to jest najprostsze.
yamma
May 20, 2012, 5:33:52 AM5/20/12
to
nie wiem na jakiej zasadzie pracuj� servlety. WCF m�g�by uruchomi� na
dowolnym koncie, nawet specjalnie do tego celu utworzonym a serwer WWW by�by
tylko czym� w rodzaju proxy - translatora, kt�ry t�umaczy�by informacje
wysy�ane z WCF na j�zyk zrozumia�y dla przegl�darki.
> Dla mnie to jest najprostsze.
.NETowiec. ;-)
yamma
Adam Przybyla
May 20, 2012, 5:36:43 AM5/20/12
to
Grzegorz Niemirowski <gnthe...@poczta.onet.pl> wrote:
> Zastanawiam się nad aplikacją webową, która pozwalałaby komunikować się
> zdalnie z jakimś sprzętem, konkretnie podłączonym przez port szeregowy do
> serwera WWW. Wysyłanie czegoś do takiego urządzenia jest dosyć proste. Gdy
> przyjdzie żądanie z przeglądarki, np. POST lub GET, można coś wysłać na port
> szeregowy, czy to korzystając z gotowych klas (PHP/ASP, zależnie w czym jest
> strona napisana), czy też wywołując zewnętrzną aplikację. Gorzej jest
> dostanie np. zrzucałaby to do pliku. Przeglądarka przez AJAX mogłaby wtedy
> odpytywać aplikację na serwerze (przez polling np. co sekundę), która
> pobierałaby ten plik.
na porcie rs-232 i komunikuje sie z aplikacja webowa. Komunikacja
po xml-rpc lub poprzez baze. Aplikacja webowa pewnei z jakas forma
ajax'a w sobie. Z powazaniem
Adam Przybyla
> Zastanawiam się nad aplikacją webową, która pozwalałaby komunikować się
> zdalnie z jakimś sprzętem, konkretnie podłączonym przez port szeregowy do
> serwera WWW. Wysyłanie czegoś do takiego urządzenia jest dosyć proste. Gdy
> przyjdzie żądanie z przeglądarki, np. POST lub GET, można coś wysłać na port
> szeregowy, czy to korzystając z gotowych klas (PHP/ASP, zależnie w czym jest
> strona napisana), czy też wywołując zewnętrzną aplikację. Gorzej jest
> natomiast w drugą stronę, bo chodzi o to, żeby to działało w czasie
> rzeczywistym. Aplikacja webowa raczej nie może otworzyć sobie portu
> szeregowego i czekać aż coś dostanie.
> Więc zostaje zewnętrzna aplikacja, która trzymałaby otwarty port i gdy coś
> rzeczywistym. Aplikacja webowa raczej nie może otworzyć sobie portu
> szeregowego i czekać aż coś dostanie.
> dostanie np. zrzucałaby to do pliku. Przeglądarka przez AJAX mogłaby wtedy
> odpytywać aplikację na serwerze (przez polling np. co sekundę), która
> pobierałaby ten plik.
> Generalnie chodzi mi o coś takiego, że jest sobie urządzenie z przyciskiem.
> Naciśnięcie tego przycisku powoduje wysłanie jednego bajtu przez RS-232 do
> komputera na którym stoi demon HTTPD. Jak to potem sensownie przesłać do
> przeglądarki, z możliwie małym opóźnieniem? Da się to jakoś lepiej rozwiązać
> Naciśnięcie tego przycisku powoduje wysłanie jednego bajtu przez RS-232 do
> komputera na którym stoi demon HTTPD. Jak to potem sensownie przesłać do
> niż komunikacja przez pliki z zewnętrzną aplikacją odpowiedzialną za port
> szeregowy?
... stawialbym na aplikacje lokalna, ktora caly czas nasluchuje
> szeregowy?
na porcie rs-232 i komunikuje sie z aplikacja webowa. Komunikacja
po xml-rpc lub poprzez baze. Aplikacja webowa pewnei z jakas forma
ajax'a w sobie. Z powazaniem
Adam Przybyla
Michoo
May 20, 2012, 8:19:46 AM5/20/12
to
On 20.05.2012 11:33, yamma wrote:
> No to teraz pozostaje rozwiązać kwestię, kto zrobi to taniej. Javowiec
> czy .NETowiec. ;-)
A poprawili już ten problem ze zwisami portu szeregowego pod .NET?
--
Pozdrawiam
Michoo
> No to teraz pozostaje rozwiązać kwestię, kto zrobi to taniej. Javowiec
> czy .NETowiec. ;-)
A poprawili już ten problem ze zwisami portu szeregowego pod .NET?
--
Pozdrawiam
Michoo
Grzegorz Niemirowski
May 20, 2012, 8:55:45 AM5/20/12
to
Michoo <micho...@vp.pl> napisał(a):
prymitywne i przestarzałe. Otóż wyobrażałem sobie to tak, że jak leci HTTP
GET to wtedy na serwerze odpala się jakieś PHP, które coś tam robi i zwraca
wynik. A taki port szeregowy musi być monitorowany cały czas, czyli musi
chodzić coś w rodzaju demona.
>> Generalnie chodzi mi o coś takiego, że jest sobie urządzenie z
>> przyciskiem. Naciśnięcie tego przycisku powoduje wysłanie jednego bajtu
>> przez RS-232 do komputera na którym stoi demon HTTPD. Jak to potem
>> sensownie przesłać do przeglądarki, z możliwie małym opóźnieniem?
> Ajax. Najlepiej jakiś framework który wywołania callbacków zrobi za
> ciebie. Ja kiedyś używałem GWT.
Dzięki.
>> Da się
>> to jakoś lepiej rozwiązać niż komunikacja przez pliki z zewnętrzną
>> aplikacją odpowiedzialną za port szeregowy?
> Nie napisałeś jaki system operacyjny - pod linuksem port szeregowy jest
> "jakimś plikiem".
Tak samo jak pod Windows i innymi systemami. A systemu nie podawałem bo
chciałem jakąś ogólną ideę, najlepiej prostą i przenośną. Jeśli już coś
miałbym wskazać to Apache (raczej na Linuksie) i PHP, bo jest to popularna
kombinacja, łatwa do wdrożenia i często już dostępna.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 3 hours, 5 minutes and 33 seconds
> On 20.05.2012 01:48, Grzegorz Niemirowski wrote:
>> Gorzej jest natomiast w drugą stronę, bo chodzi o
>> to, żeby to działało w czasie rzeczywistym. Aplikacja webowa raczej nie
>> może otworzyć sobie portu szeregowego i czekać aż coś dostanie.
> Ponieważ?
> Albo servlet javy na serwerze aplikacji z dodatkową klasą ładowaną w init
> (tomcat/glassfish/etc), albo np aplikacja w C++ podpięta przez fastcgi do
> apache.
OK, nie znam się na servletach i fast CGI i stąd moje myślenie jest pewnie
>> Gorzej jest natomiast w drugą stronę, bo chodzi o
>> to, żeby to działało w czasie rzeczywistym. Aplikacja webowa raczej nie
>> może otworzyć sobie portu szeregowego i czekać aż coś dostanie.
> Ponieważ?
> Albo servlet javy na serwerze aplikacji z dodatkową klasą ładowaną w init
> (tomcat/glassfish/etc), albo np aplikacja w C++ podpięta przez fastcgi do
> apache.
prymitywne i przestarzałe. Otóż wyobrażałem sobie to tak, że jak leci HTTP
GET to wtedy na serwerze odpala się jakieś PHP, które coś tam robi i zwraca
wynik. A taki port szeregowy musi być monitorowany cały czas, czyli musi
chodzić coś w rodzaju demona.
>> Generalnie chodzi mi o coś takiego, że jest sobie urządzenie z
>> przyciskiem. Naciśnięcie tego przycisku powoduje wysłanie jednego bajtu
>> przez RS-232 do komputera na którym stoi demon HTTPD. Jak to potem
>> sensownie przesłać do przeglądarki, z możliwie małym opóźnieniem?
> Ajax. Najlepiej jakiś framework który wywołania callbacków zrobi za
> ciebie. Ja kiedyś używałem GWT.
>> Da się
>> to jakoś lepiej rozwiązać niż komunikacja przez pliki z zewnętrzną
>> aplikacją odpowiedzialną za port szeregowy?
> Nie napisałeś jaki system operacyjny - pod linuksem port szeregowy jest
> "jakimś plikiem".
chciałem jakąś ogólną ideę, najlepiej prostą i przenośną. Jeśli już coś
miałbym wskazać to Apache (raczej na Linuksie) i PHP, bo jest to popularna
kombinacja, łatwa do wdrożenia i często już dostępna.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Tomasz Sowa
May 20, 2012, 8:54:53 AM5/20/12
to
Dnia Sun, 20 May 2012 01:48:06 +0200, Grzegorz Niemirowski napisał(a):
> Przeglądarka przez AJAX mogłaby wtedy
> odpytywać aplikację na serwerze (przez polling np. co sekundę), która
> pobierałaby ten plik.
I kilka takich przeglądarek i serwer zajechany:
> Przeglądarka przez AJAX mogłaby wtedy
> odpytywać aplikację na serwerze (przez polling np. co sekundę), która
> pobierałaby ten plik.
http://en.wikipedia.org/wiki/WebSocket
--
Tomek
Grzegorz Niemirowski
May 20, 2012, 9:13:25 AM5/20/12
to
Tomasz Sowa <t...@ttmath.NOSPAM.org> napisał(a):
użytkownika.
> http://en.wikipedia.org/wiki/WebSocket
Tak, znam, polling był podany przykładowo. Najbardziej interesuje mniej
stały monitoring portu przez serwer WWW.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 3 hours, 28 minutes and 2 seconds
> I kilka takich przeglądarek i serwer zajechany:
Tak, ale tu akurat miałem na myśli rozwiązanie dla tylko jednego
użytkownika.
> http://en.wikipedia.org/wiki/WebSocket
Tak, znam, polling był podany przykładowo. Najbardziej interesuje mniej
stały monitoring portu przez serwer WWW.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Michoo
May 20, 2012, 10:28:14 AM5/20/12
to
On 20.05.2012 14:55, Grzegorz Niemirowski wrote:
> Je�li ju� co�
> mia�bym wskaza� to Apache (raczej na Linuksie) i PHP, bo jest to
> popularna kombinacja, �atwa do wdro�enia i cz�sto ju� dost�pna.
>
Nie znam na tyle php, �eby powiedzie� czy to b�dzie dzia�a�. mod_fcgi
obs�uguje tak� prac� (przy pierwszym ��daniu odpalony 1 proces
obs�uguj�cy kolejne zg�oszenia, zako�czony po ustawionym timeoucie), ale
czy da si� i jak spi�� z tym PHP - nie wiem.
--
Pozdrawiam
Michoo
> Je�li ju� co�
> mia�bym wskaza� to Apache (raczej na Linuksie) i PHP, bo jest to
> popularna kombinacja, �atwa do wdro�enia i cz�sto ju� dost�pna.
>
Nie znam na tyle php, �eby powiedzie� czy to b�dzie dzia�a�. mod_fcgi
obs�uguje tak� prac� (przy pierwszym ��daniu odpalony 1 proces
obs�uguj�cy kolejne zg�oszenia, zako�czony po ustawionym timeoucie), ale
czy da si� i jak spi�� z tym PHP - nie wiem.
--
Pozdrawiam
Michoo
yamma
May 20, 2012, 11:14:44 AM5/20/12
to
Michoo wrote:
> On 20.05.2012 11:33, yamma wrote:
>> No to teraz pozostaje rozwi�za� kwesti�, kto zrobi to taniej.
> On 20.05.2012 11:33, yamma wrote:
>> Javowiec czy .NETowiec. ;-)
> A poprawili juďż˝ ten problem ze zwisami portu szeregowego pod .NET?
Nie wiem. Nie bawi�em si� nigdy obs�ug� port�w.
yamma
Edek Pienkowski
May 20, 2012, 2:19:35 PM5/20/12
to
Dnia Sun, 20 May 2012 15:13:25 +0200, Grzegorz Niemirowski napisal:
> Tomasz Sowa <t...@ttmath.NOSPAM.org> napisał(a):
>> I kilka takich przeglądarek i serwer zajechany:
>
> Tak, ale tu akurat miałem na myśli rozwiązanie dla tylko jednego
> użytkownika.
>
>> http://en.wikipedia.org/wiki/WebSocket
>
> Tak, znam, polling był podany przykładowo. Najbardziej interesuje mniej
> stały monitoring portu przez serwer WWW.
Można przebić się tunelem przez proxy http w ten sposób: jest jedno
żądanie GET (stream down) i jedno żądanie POST (stream up). Po stronie
serwera można to obsłużyć czymkolwiek - nie mam bookmarka, ale w bashu się
da - tylko nie wiem, jak to jest po stronie przeglądarki, czy Javascript
lub cokolwiek innego pozwala obsłużyc takie dwa nieskończone requesty.
Tylko pomysł. Miałby taką zaletę, że nie ma żadnego aktywnego polla,
co najwyżej pingi na dwóch żądaniach.
Edek
> Tomasz Sowa <t...@ttmath.NOSPAM.org> napisał(a):
>> I kilka takich przeglądarek i serwer zajechany:
>
> Tak, ale tu akurat miałem na myśli rozwiązanie dla tylko jednego
> użytkownika.
>
>> http://en.wikipedia.org/wiki/WebSocket
>
> Tak, znam, polling był podany przykładowo. Najbardziej interesuje mniej
> stały monitoring portu przez serwer WWW.
żądanie GET (stream down) i jedno żądanie POST (stream up). Po stronie
serwera można to obsłużyć czymkolwiek - nie mam bookmarka, ale w bashu się
da - tylko nie wiem, jak to jest po stronie przeglądarki, czy Javascript
lub cokolwiek innego pozwala obsłużyc takie dwa nieskończone requesty.
Tylko pomysł. Miałby taką zaletę, że nie ma żadnego aktywnego polla,
co najwyżej pingi na dwóch żądaniach.
Edek
Grzegorz Niemirowski
May 20, 2012, 6:40:10 PM5/20/12
to
Michoo <micho...@vp.pl> napisał(a):
http://connect.microsoft.com/VisualStudio/feedback/details/584116/serialport-bug-regarding-dcb-fabortonerror-flag
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 12 hours, 56 minutes and 54 seconds
> On 20.05.2012 11:33, yamma wrote:
>> No to teraz pozostaje rozwiązać kwestię, kto zrobi to taniej. Javowiec
>> czy .NETowiec. ;-)
> A poprawili już ten problem ze zwisami portu szeregowego pod .NET?
Wygląda na to, że nie. Ktoś musi kopnąć ich w tyłek.
>> No to teraz pozostaje rozwiązać kwestię, kto zrobi to taniej. Javowiec
>> czy .NETowiec. ;-)
> A poprawili już ten problem ze zwisami portu szeregowego pod .NET?
http://connect.microsoft.com/VisualStudio/feedback/details/584116/serialport-bug-regarding-dcb-fabortonerror-flag
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
darekm
May 21, 2012, 4:10:08 AM5/21/12
to
W dniu 2012-05-20 01:48, Grzegorz Niemirowski pisze:
> do serwera WWW.
Coś takiego: http://rcp.madar.com.pl ?
A dokładnie: czytnik RFID podłączony vie RS 232 . CO prawda serwer co
ARM ale komunikacja z całym urządzeniem poprzez WWW.
Wysyłanie czegoś do takiego urządzenia jest dosyć
> proste. Gdy przyjdzie żądanie z przeglądarki, np. POST lub GET, można
> coś wysłać na port szeregowy, czy to korzystając z gotowych klas
> (PHP/ASP, zależnie w czym jest strona napisana), czy też wywołując
> zewnętrzną aplikację. Gorzej jest natomiast w drugą stronę, bo chodzi o
serwerze.
> Więc zostaje zewnętrzna aplikacja, która trzymałaby otwarty port i gdy
> coś dostanie np. zrzucałaby to do pliku. Przeglądarka przez AJAX mogłaby
razu, tylko czeka. Jeżeli przyjdzie sygnał z zewnętrznego urządzenia do
serwer WWW natychmiast odpowiada, jeżeli nie to po upływie 60s leci
pusta odpowiedź, po czym przeglądarka ponawia pytanie.
> Generalnie chodzi mi o coś takiego, że jest sobie urządzenie z
> przyciskiem. Naciśnięcie tego przycisku powoduje wysłanie jednego bajtu
> przez RS-232 do komputera na którym stoi demon HTTPD. Jak to potem
> sensownie przesłać do przeglądarki, z możliwie małym opóźnieniem?
Opóźnienie jest rzędu kilkuset milisekund
Da się
> to jakoś lepiej rozwiązać niż komunikacja przez pliki z zewnętrzną
> aplikacją odpowiedzialną za port szeregowy?
>
to raczej nie ma znaczenia.
--
Darek
> Zastanawiam się nad aplikacją webową, która pozwalałaby komunikować się
> zdalnie z jakimś sprzętem, konkretnie podłączonym przez port szeregowy
> do serwera WWW.
Coś takiego: http://rcp.madar.com.pl ?
A dokładnie: czytnik RFID podłączony vie RS 232 . CO prawda serwer co
ARM ale komunikacja z całym urządzeniem poprzez WWW.
Wysyłanie czegoś do takiego urządzenia jest dosyć
> proste. Gdy przyjdzie żądanie z przeglądarki, np. POST lub GET, można
> coś wysłać na port szeregowy, czy to korzystając z gotowych klas
> zewnętrzną aplikację. Gorzej jest natomiast w drugą stronę, bo chodzi o
> to, żeby to działało w czasie rzeczywistym. Aplikacja webowa raczej nie
> może otworzyć sobie portu szeregowego i czekać aż coś dostanie.
Teoretycznie może, ale odbędzie się to na komputerze klienta, a nie na
> może otworzyć sobie portu szeregowego i czekać aż coś dostanie.
serwerze.
> Więc zostaje zewnętrzna aplikacja, która trzymałaby otwarty port i gdy
> wtedy odpytywać aplikację na serwerze (przez polling np. co sekundę),
> która pobierałaby ten plik.
Lepiej zrobić to inaczej. Przeglądarka pyta, ale serwer nie odpowiada od
> która pobierałaby ten plik.
razu, tylko czeka. Jeżeli przyjdzie sygnał z zewnętrznego urządzenia do
serwer WWW natychmiast odpowiada, jeżeli nie to po upływie 60s leci
pusta odpowiedź, po czym przeglądarka ponawia pytanie.
> Generalnie chodzi mi o coś takiego, że jest sobie urządzenie z
> przyciskiem. Naciśnięcie tego przycisku powoduje wysłanie jednego bajtu
> przez RS-232 do komputera na którym stoi demon HTTPD. Jak to potem
> sensownie przesłać do przeglądarki, z możliwie małym opóźnieniem?
Da się
> to jakoś lepiej rozwiązać niż komunikacja przez pliki z zewnętrzną
> aplikacją odpowiedzialną za port szeregowy?
>
--
Darek
Jacek Czerwinski
May 22, 2012, 1:33:22 AM5/22/12
to
W dniu 2012-05-21 10:10, darekm pisze:
Dla mnie tow tym przypadku chore patrzenie, wywodzące się z serwerów
wirtualnych (i 'jednostrzałowych' skryptów). Prowadzi do gubienia danych
(gdy nikt ich nie czyta) itd.
To MOŻE mieć sens w INNYCH okolicznościach. W innych okolicznościach
pewien typowy styl projektowania "nie ma części rezydentnej (wątku)" by
był ciekawy, ale tu jest masochizmem. Dodam, że ulubiony język tych
rozwiązań do dziś nie dorobił się stabilnych wątków i ich otoczenia, o
czymś to świadczy
Z portem musi się komunikować coś rezydentnego, "długotrwały" program.
> Lepiej zrobić to inaczej. Przeglądarka pyta, ale serwer nie odpowiada od
> razu, tylko czeka. Jeżeli przyjdzie sygnał z zewnętrznego urządzenia do
> serwer WWW natychmiast odpowiada, jeżeli nie to po upływie 60s leci
> pusta odpowiedź, po czym przeglądarka ponawia pytanie.
A jeśli odpowiedź z portu "by była" pół sekundy przed pytaniem przeglądarki?
> razu, tylko czeka. Jeżeli przyjdzie sygnał z zewnętrznego urządzenia do
> serwer WWW natychmiast odpowiada, jeżeli nie to po upływie 60s leci
> pusta odpowiedź, po czym przeglądarka ponawia pytanie.
Dla mnie tow tym przypadku chore patrzenie, wywodzące się z serwerów
wirtualnych (i 'jednostrzałowych' skryptów). Prowadzi do gubienia danych
(gdy nikt ich nie czyta) itd.
To MOŻE mieć sens w INNYCH okolicznościach. W innych okolicznościach
pewien typowy styl projektowania "nie ma części rezydentnej (wątku)" by
był ciekawy, ale tu jest masochizmem. Dodam, że ulubiony język tych
rozwiązań do dziś nie dorobił się stabilnych wątków i ich otoczenia, o
czymś to świadczy
Z portem musi się komunikować coś rezydentnego, "długotrwały" program.
darekm
May 22, 2012, 3:54:11 AM5/22/12
to
W dniu 2012-05-22 07:33, Jacek Czerwinski pisze:
to dostanie w tym lub następnym pytaniu, opóźnienie nie większe niż
kilkaset milisekund. Nie ma mowy o jakimkolwiek gubieniu danych.
>
> Dla mnie tow tym przypadku chore patrzenie, wywodzące się z serwerów
> wirtualnych (i 'jednostrzałowych' skryptów). Prowadzi do gubienia danych
> (gdy nikt ich nie czyta) itd.
skąd wiesz?
>
> To MOŻE mieć sens w INNYCH okolicznościach. W innych okolicznościach
> pewien typowy styl projektowania "nie ma części rezydentnej (wątku)" by
> był ciekawy, ale tu jest masochizmem. Dodam, że ulubiony język tych
> rozwiązań do dziś nie dorobił się stabilnych wątków i ich otoczenia, o
> czymś to świadczy
>
> Z portem musi się komunikować coś rezydentnego, "długotrwały" program.
Może się źle wypowiedziałem. Właśnie tak coś takiego jest realizowane.
Osobny wątek do obsługi urządzenia, osobny do komunikacji. Sam serwer
HTTP jest wbudowany w program bo na urządzeniach to lepiej chodzi (ale
też mogę podłączyć via fastcgi). I z pewnością nie używam "ulubionego
języka tych rozwiązań" cokolwiek to znaczy.
--
Darek
> W dniu 2012-05-21 10:10, darekm pisze:
>> Lepiej zrobić to inaczej. Przeglądarka pyta, ale serwer nie odpowiada od
>> razu, tylko czeka. Jeżeli przyjdzie sygnał z zewnętrznego urządzenia do
>> serwer WWW natychmiast odpowiada, jeżeli nie to po upływie 60s leci
>> pusta odpowiedź, po czym przeglądarka ponawia pytanie.
>
> A jeśli odpowiedź z portu "by była" pół sekundy przed pytaniem
> przeglądarki?
w czym problem? Przed pierwszym pytaniem to nas nie interesuje, pomiędzy
>> Lepiej zrobić to inaczej. Przeglądarka pyta, ale serwer nie odpowiada od
>> razu, tylko czeka. Jeżeli przyjdzie sygnał z zewnętrznego urządzenia do
>> serwer WWW natychmiast odpowiada, jeżeli nie to po upływie 60s leci
>> pusta odpowiedź, po czym przeglądarka ponawia pytanie.
>
> A jeśli odpowiedź z portu "by była" pół sekundy przed pytaniem
> przeglądarki?
to dostanie w tym lub następnym pytaniu, opóźnienie nie większe niż
kilkaset milisekund. Nie ma mowy o jakimkolwiek gubieniu danych.
>
> Dla mnie tow tym przypadku chore patrzenie, wywodzące się z serwerów
> wirtualnych (i 'jednostrzałowych' skryptów). Prowadzi do gubienia danych
> (gdy nikt ich nie czyta) itd.
>
> To MOŻE mieć sens w INNYCH okolicznościach. W innych okolicznościach
> pewien typowy styl projektowania "nie ma części rezydentnej (wątku)" by
> był ciekawy, ale tu jest masochizmem. Dodam, że ulubiony język tych
> rozwiązań do dziś nie dorobił się stabilnych wątków i ich otoczenia, o
> czymś to świadczy
>
> Z portem musi się komunikować coś rezydentnego, "długotrwały" program.
Osobny wątek do obsługi urządzenia, osobny do komunikacji. Sam serwer
HTTP jest wbudowany w program bo na urządzeniach to lepiej chodzi (ale
też mogę podłączyć via fastcgi). I z pewnością nie używam "ulubionego
języka tych rozwiązań" cokolwiek to znaczy.
--
Darek
0 new messages