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

do góry

Michoo wrote:
> 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?

Nie wiem. Nie bawiłem się nigdy obsługą portów.
yamma

do góry

Dnia Sun, 20 May 2012 15:13:25 +0200, Grzegorz Niemirowski napisal:

> Tomasz Sowa <t...@t...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

do góry

Michoo <m...@v...pl> napisał(a):
> 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.
http://connect.microsoft.com/VisualStudio/feedback/d
etails/584116/serialport-bug-regarding-dcb-fabortone
rror-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

do góry

W dniu 2012-05-20 01:48, Grzegorz Niemirowski pisze:
> 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
> (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.

Teoretycznie może, ale odbędzie się to na komputerze klienta, a nie na
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
> 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
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

do góry

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?

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.

do góry

W dniu 2012-05-22 07:33, Jacek Czerwinski pisze:
> 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
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

do góry