Newsgroup: it.hobby.elettronica.digitale
Titolo: Web server

Ciao,
volevo provare a fare qualche esperimento con i web server per 
recuperare da remoto dei dati (telemetria) oppure inviare comandi.
Dai ricordi di info II all'università riesco a scrivere un programmino 
client/serve in linux (oppure a configurare direttamente un web server).
Ho però una lacuna importante: supponiamo come primo esempio di 
collegare il mio serverino al router di casa.
Attualmente se da remoto mi connetto via http all'ip di detto router 
accedo al suo http-server (pagina di configurazione).
Posso impostare il router affinché inoltri le richieste http a un 
indirizzo lan specifico (appunto il mio server). Così facendo però perdo 
la possibilità di accedere alla pagina di configurazione inziale, giusto?
In altre parole: non è possibile avere più di un server per indirizzo 
ip, ad esempio usando le porte?
Marco

 la possibilità di accedere alla pagina di configurazione inziale, giusto?
La pagina di configurazione del tuo router si può vedere da fuori?
Gulp!
Invece della porta 80 puoi configurare il server per ricevere le richieste
HTTP sulla porta, ad esempio, 81
Per accedervi basta scrivere, nell'indirizzo del browser client,
http://tuo_indirizzo_ip:81
-- 
Ma non si può intendere se prima non s'impara a intender la lingua

 
http://tuo_indirizzo_ip:81
Ah perfetto, quello che volevo.
Quindi potrei avere n server ciascuno che risponde su una porta diversa.
Grazie.
Marco

 Quindi potrei avere n server ciascuno che risponde su una porta diversa.
Si, sia sullo stesso pc, sia su pc diversi della stessa rete, basta dire 
al router verso quale IP della rete interna rigirare i dati indirizzati 
ad ogni specifica porta. Meglio usare porte alte, ad esempio 8000, 8080 
ecc. Va da se' che i pc devono avere un ip fisso, mentre per il router 
e' meglio, ma si puo' fare anche con ip dinamico appoggiandosi a un 
"servizio ponte" (contattato periodicamente dal server) che faccia un 
redirect (se hai uno spazio web che accetta script php e' banale).
ciao
Claudio_F

 redirect (se hai uno spazio web che accetta script php e' banale).
Si, su questo avevo già giocato usanto dyndns (per un ftp) e funziona 
senza problemi.
I primi pasticci li faccio usando un netbook con su linux (tinycore).
Secondo la vostra esperienza, volendo poi passare a schede embedded (ARM 
ad esempio) conviene sempre appoggiarsi a un SO così da avere le API 
belle pronte o addirittura il server stesso oppure si può fare anche 
direttamente tramite stack TCP/IP?
Quante risorse occupa servire un client? Ad esempio supponiamo che il 
server ad ogni client debba fornire una stringa (ipotizziamo contente 
tutti i dati della telemetria) e ricevere alcuni comandi. Questo ogni 
qualche secondo.
Pensare che questo serverino possa servire 30-40 client 
"contemporaneamente" è fattibile?
Marco

 qualche secondo.
Piu' che un web server da contattare con un browser mi sembra che stai 
descrivendo due applicazioni client/server "custom" che dialogano 
attraverso la rete (banali stringhe attraverso socket quindi, senza 
request/response http ecc), in questo caso velocita' e utilizzo risorse 
sono migliori. Pero' non so quantificare.
Claudio_F

 "contemporaneamente" è fattibile?
Dipende tutto dalla persistenza del collegamento. Se fai un web server
"originale", in cui ogni domanda/risposta è una connessione che muore dopo
lo scambio, è semplice. Se invece la transazione deve essere persistente o
con cookie è già un po' più complicato.
Quante pagine hai? Che livello di sicurezza dalle intrusioni ti serve?
Insaomma, cosa fa l'applicazione?


 Insaomma, cosa fa l'applicazione?
Niente, non è un caso reale.
Sto solo cercando di imparare qualcosa perché questo argomento (come 
tanti altri) mi è ancora fumoso.
Facciamo finta di avere una scheda centrale ( = server) che acquisisce i 
suoi bravi sensori. Aggiungiamoci anche un GPS giusto per avere qualche 
stringa oltre a dati numerici e digitali. Questo server (UDP a sto 
punto, nessuna pagina html) è connesso a Internet tramite un router.
Ora, vorrei che collegando a Internet delle altre schedine client, 
potessero ricevere questi dati, ma soprattutto averli aggiornati ogni 
pochi secondi.
Quindi sarebbe bello avere una connessione permanente (credo) per 
evitare di dover ricollegare ogni volta client e server.
E qui appunto mi era venuto in mente il discorso di quante connessioni 
al massimo potrei riuscire a gestire.
Quanto alla protezione... non ho idea di cosa si può fare.
Questo sarebbe il primo step... poi potrei passare a creare qualche 
pagina html, ma non tutto assieme :)
Ciao!
Marco

 evitare di dover ricollegare ogni volta client e server.
La rete IP e' intrinsecamente connectionless... il TCP crea una specie 
di connessione al livello di trasporto che garantisce l'integrita' e la 
consegna dei dati (a differenza dell'UDP), ma non la vedrei come una 
connessione da tenere costantemente aperta per la durata di un'intera 
sessione... anche le richieste che partono da un browser aprono una 
connessione TCP per effettuare una request, ottenere l'HTML di ritorno e 
chiudono.
Un'applicazione web based e' composta da innumerevoli step di 
connessioni aperte/chiuse con le quali trasmettere anche informazioni 
riguardanti un'eventuale sessione, elaborata pero' a livello 
applicazione e non di trasporto. E questo e' particolarmente vero nel 
caso di HTTP server.
Poi non ci dici con quale linguaggio penseresti di pasticciare :)
ciao
Claudio_F

 Poi non ci dici con quale linguaggio penseresti di pasticciare :)
In effetti davo per scontato C/C++, utilizzabili anche su piattaforme 
meno prestanti.
Marco

 si dovrebbero riuscire a servire molti più client.
Se è necessario che nessun dato venga perso. Altrimenti, se è più
importante la tempestività, è meglio usare UDP.
In caso di problemi temporanei sulla rete con TCP i dati ritarderanno per
via dei retry, con UDP li perdi ma non vai ad intasare la connessione
residua.
Con due datagram UDP, interrogazione e risposta, hai fatto tutto. Anzi,
puoi anche mandare un datagram solo che richieda, ad esempio, 10 campioni,
uno ogni 10 secondi.
Invece, solo per aprire e chiudere una connessione TCP senza trasmettere
dati occorrono sei datagram.
Senza contare che un pacchetto UDP ha 8 byte di overhead, TCP 20 o più.


 chiudono.
HTTP/1.1 ha le connessioni persistenti però, per ottimizzare le 
richieste necessaria ad ottenere tutte le risorse di una pagina.

 evitare di dover ricollegare ogni volta client e server.
Finché non lo chiudi il canale TCP dovrebbe restare aperto, salvo errori.

 "contemporaneamente" è fattibile?
Recentemente ho letto alcune analisi comparative di server http, ci sono 
diversi tipi di famiglie, di scuole di pensiero su come realizzare un 
server a seconda delle necessità.
Al momento non ricordo il titolo della pagina, vedrò se l'ho salvata tra 
i segnalibro.
30-40 client probabilmente li metterai in coda per servirli con un certo 
numero di worker, non contemporaneamente ma quasi.
Ho trovato anche diversi server http minimali, mi pare addirittura 
cercando nel repository standard di Debian Lenny, in C e ovviamente con 
i sorgenti disponibili.

 Gulp!
Non è mica tanto raro, è possibile in molti router che ho visto.
O forse intendevi che è un problema per la sicurezza?

 Senza contare che un pacchetto UDP ha 8 byte di overhead, TCP 20 o più.
Ok grazie delle info.
Proverò a fare qualcosa e poi vedrò come si comporta.
Ciao!
Marco

 i sorgenti disponibili.
Ottimo, ci darò un'occhiata.
Marco

 Proverň a fare qualcosa e poi vedrň come si comporta.
Se vuoi poter interagire con umani, ti serve HTTP e quindi TCP. 
Per il machine to machine, UDP non solo č piů leggero, ma anche piů
"governabile" ed adattabile alle tue esigenze.
-- 
Ma non si puň intendere se prima non s'impara a intender la lingua

 ip, ad esempio usando le porte?
Hai voglia... :D
Veramente, se sali di livello, e limitatamente ad alcuni protocolli, puoi 
avere più di un server anche con un solo IP e una sola porta, ma lì andiamo 
già ben oltre quel che ti serve.
Butta un occhio alle configuirazioni di NAT, Port Forwarding, Virtual 
Server (o come le chiama il tuo router)... da qualche parte potrai dire al 
tuo router che le connessioni in entrata alla porta X le deve reindirizzare 
alla porta Y dell'IP Z.Z.Z.Z.
BTW: se il tuo router non è una macchina "seria" e aggiornata 
costantemente, io fossi in te eviterei caldamente di lasciare la pagina di 
configurzione accessibile dall'esterno, ANCHE se ci metti la password più 
sicura del mondo. 


wrote:

Trovi addirittura webserver basati su MSP430!
Prova a cercare sul web :-)
http://www.rowley.co.uk/msp430/uip.htm
http://microcontrollershop.com/product_info.php?products_id=741
http://www.olimex.com/dev/mspprojects.html
Oppure atmel avr
http://shop.tuxgraphics.org/electronic/index-eth.html
http://www.mikrocontroller.com/eng/avr_webserver.php
http://www.embedds.com/avr-web-server-project/

 "governabile" ed adattabile alle tue esigenze.
Ottimo riassunto.
Concludendo quindi mi serve imparare entrambe le cose, 'n si sa mai.
Marco

 
http://www.embedds.com/avr-web-server-project/
Slurp! Ho giusto ordinato qualche schedina di sviluppo per MSP430 su 
digikey!
Marco

 sicura del mondo.
E' un fritz.box, in realtà l'avevo attivata qualche tempo fa quando 
facevo le prove da remoto per configurare bene l'inoltro delle chiamate 
a altre amenità.
Ora che è tutto a posto l'ho disattivata.
Marco

 Concludendo quindi mi serve imparare entrambe le cose, 'n si sa mai.
Io non sarei cosě dicotomico come Bertolazzi.
UDP č piů leggero, perché:
- Non garantisce l'arrivo dei datagrammi (ma se arrivano, sono integri)
- Anche se arrivano non č garantito l'ordine.
Quindi č ok se devi avere un flusso di dati continuo a basso overhead 
dove č accettabile perdere pacchetti (applicazioni tipiche: streaming 
audio e video), ma non va bene se pensi di usarlo come useresti una 
seriale. In questo ultimo caso č meglio il TCP anche se la 
comunicazione č m2m.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org

 è m2m.
Per le possibili applicazioni che ho in mente direi che allora ho 
bisogno quasi esclusivamente del TCP.
Comunque farò prove in entrambe le strade.
Tra parentesi, Bertos in questo senso offre qualcosa? :)
Marco

 Tra parentesi, Bertos in questo senso offre qualcosa? :)
Abbiamo fatto un port di lwIP che non č stato ancora pubblicato.
Obbligatoriamente entro la fine dell'anno deve essere terminato (serve 
per un cliente).
Quindi direi di sě :-)
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 Quindi direi di sě :-)
Ottimo :)
Marco

 Io non sarei così dicotomico come Bertolazzi.
Forse sarebbe meglio leggere cos'ha scritto Bertolazzi prima di dargli del
dicotomico e ripetere una parte di quanto ha già scritto.
Hai fatto molti lavori in UDP? E in TCP?
-- 
Ma non si può intendere se prima non s'impara a intender la lingua

 dicotomico e ripetere una parte di quanto ha già scritto.
Questa terza persona inizialmente m'ha spiazzato. Dicotomico non è mica 
un'offesa.

 ha scritto:

Vero, io l'ho letto come 'categorico' o 'tranchant' , niente di offensivo.
Il pensiero dicotomico è quello che tende a dividere in due le cose: buoni -
cattivi, bianchi - neri, ecc.
--
ciao
  Stefano

 dicotomico e ripetere una parte di quanto ha già scritto.
We nun te scaldà, mica è un'offesa eh.
Mi riferivo al tuo ultimo post, quando sembrava che tu avessi fatto una 
divisione netta sull'uso dei protocolli: con umani si usa il TCP, per 
l'm2m l'UDP.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 cattivi, bianchi - neri, ecc.
Quindi non è un complimento, presuppone una risoluzione a 1 singolo bit, ma
non è assolutamente questo il punto. Figurati se me la prendo, perdipiù con
una persona così gentile e preparata come Sacchi.
Mi pare di aver spiegato diffusamente pregi e difetti di TCP e UDP, mentre
lui ha solo ripetuto la definizione da manuale.
E poi mi dà del dicotomico. :D


 Mi riferivo al tuo ultimo post
Ed infatti ti esortavo a leggere gli altri, basati sulla mia esperienza su
reti reali e non solo sulla definizione di TCP e UDP.


 si dovrebbero riuscire a servire molti più client.
Se ne servono infinitamente di più senza aprire connessioni, le quali, tra
l'altro, ti occupano, oltre che cicli per recuperarle e gestirle, anche
RAM.
Ho quasi la tenzazione di confermare l'affermazione che non ho mai fatto:
per l'm2m è meglio UDP.
In effetti i i protocolli internet a livello applicazione con interazione
umana (SMTP, telnet, FTP, HTTP, IRC, SSH) sono basati su TCP, quelli
tipicamente m2m (DHCP, NFS, SNMP, RIP, DNS) su UDP.


 reti reali e non solo sulla definizione di TCP e UDP.
Proprio perché ho avuto esperienze probabilmente diverse dalle tue sono 
intervenuto.
Per chi vede la rete la prima volta, l'UDP può trarre in inganno.
Ho visto dei miei clienti tentare di portare un protocollo da seriale a 
UDP, e scontrarsi con la perdita dei datagrammi o l'arrivo degli stessi 
in ordine inverso. Per ovviare a questi problemi davano un ACK per ogni 
datagramma, facevo il reinvio e pure il riordino dei pacchetti. Si erano 
praticamente reiventati il TCP.
E' per questo che credo che la scelta del protocollo non può essere 
fatta sulla base di "cosa" devo fare, ma piuttosto sul "come".


 fatta sulla base di "cosa" devo fare, ma piuttosto sul "come".
A me, in compenso, sfugge cosa tu voglia dire con questa frase.


 A me, in compenso, sfugge cosa tu voglia dire con questa frase.
Parafrasando e riassumendo, tu dici:
comunicazioni con umani -> TCP
comunicazioni m2m -> UDP
Quindi "cosa" vuoi fare implica la scelta protocollo.
Io invece ritengo che anche il "come" vuoi farlo sia da considerare per 
la scelta.
Tutto qua,
Ciao


 la scelta.
Se per "come" intendi "fregandosene delle effettive necessità e possibilità
di comunicazione" siamo d'accordo.


 di comunicazione" siamo d'accordo.
Per "come" intendo considerando anche il bagaglio di esperienze dello 
sviluppatore e il riuso di eventuali protocolli e codice già scritto che 
funzionano su un canale diverso.


 grattacapi nella prima volta che usa la rete.
Così, una volta gli servisse grattarsi il capo, non avrà né tempo né voglia
di fare le cose per bene. Ricordi una delle sue prime risposte? "E solo un
esperimento concettuale", non non ha detto proprio così, ma non è certo con
l'acqua alla gola per una consegna (nel qual caso neppure io avrei avuto
dubbi, per ottimizzare c'è sempre tempo), vuole solo imparare qualcosa di
nuovo.


bisogna sapere cosa si fa e cosa non si fa e, soprattutto, perché.
Non ho compreso molto questo ragionamento, ma direi proprio che si, sei
dicotomico    :-P
Però io sapevo la differenza tra UDP e TCP proprio per aver provato una
simulazione di RS232 attraverso la rete locale in VB.
Sono partito da questo sorgente:
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=43963&lngWId=1
che permette di cambiare facilmente tra UDP e TCP.
Per la verità in rete locale non ho visto differenze tra i due mentre in
internet ho usato TCP, soprattutto perchè più sicuro.
--
ciao
  Stefano

 nuovo.
Devo dare ragione a entrambi. Confermo che non ho un lavoro in questo 
senso, quindi non ho scadenze, ma prima o poi mi capiterà quindi volevo 
portarmi avanti e studiare un po' la cosa.
Per cui proverò entrambe le strade (UPD e TCP) cercando di ritrovare i 
punti salienti che avete esposto qui e capire appunto quando mi converrà 
utilizzare l'uno o l'altro protocollo.
Ho qui una schedina di sviluppo LM 6965 che è ottima per fare pratica.
Nel frattempo ho recuperato il libro dei protocolli di rete utilizzato 
in uni... così mi riguardo bene anche la teoria.
Grazie!
Marco

 internet ho usato TCP, soprattutto perchè più sicuro.
In che senso più sicuro? Anche i dati che trasmettevo in GPRS erano
riservati, non segreti, per cui un po' di scrambling avanzava.
All'Italsider, quando ho sostituito il software del PC hand-held che
comunicava via radio le letture dei codici a barre delle vergelle per
passare da TCP a UDP, ho raddoppiato la (scarsissima) autonomia delle
batterie perché, in questo modo, effettuavo, quando non riusciva a
trasmettere (il capannone era enorme e pieno di ferraglia), un tentativo di
trasmissione ogni 10 secondi, invece dei convulsi tentativi di TCP. Appena
rientrava in contatto spediva i dati che si era pazientemente memorizzato
senza aver "atterrato" la batteria.
Invece il software per comunicare le pesate dei camion via fibra ottica
l'ho fatto in TCP.
Se un giorno vi capitasse un canale di comunicazione meno che ideale e con
limitazioni tipo quelle che ho elencato, con TCP avrete dei problemi.
Discutere sul fatto se sia meglio TCP o UDP è come discutere se sia meglio
il formato GIF (o PNG) o il JPG. Sono cose diverse adatte per cose diverse
ed occorrono entrambe.


ed occorrono entrambe.
Su questo sono d'accordissimo, l'importante è capire la differenza tra TCP e UDP
e quando è il caso di usare uno o l'altro, in questo thread si è cercato di fare
chiarezza, speriamo che qualcuno abbia imparato qualcosa di utile.
--
ciao
  Stefano

 chiarezza, speriamo che qualcuno abbia imparato qualcosa di utile.
Che era poi la (seconda) domanda di Marco. :-)


Che era poi la (seconda) domanda di Marco. :-)
Siamo qui apposta  :-)
--
ciao
  Stefano

 Siamo qui apposta  :-)
Sono commosso :)
Marco

Marco Trapanese:

Sě, perň, quando a furia di contributi (spesi per mantenere un Sud ignavo e
quindi ingrato) per noi e/o i nostri dipendenti saremo alla canna del gas,
ricordati di noi genitori virtuali. :-|
-- 
Ma non si puň intendere se prima non s'impara a intender la lingua