La domanda e': a che servono i timer?
-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Italian [Risolto ma abbandonato sukkia troppe risorse] [B4J B4A] TIMER
- Thread starter ivanomonti
- Start date
- Similar Threads Similar Threads
La domanda e': a che servono i timer?
molto semplice i timer servono per muovere domande e risposte in quanto le app non sono collegate attraverso atri aggeggi se non con un server mysql, non so se mysql ha un lato di programmazione di eventi al punto tale da eliminare il server creato in b4j
avevo postato il disegno ma lo ripsiego
b4j = server (NON CLASSICO) legge le domande ogni tot tempo e risponde alle domande aggiornardo il record domande
b4a-b4i-b4j = client pone le domande e legge le risposte del server (vedi server)
mysql = contenitore di domande e risposte
client e serve lavorano in modo separato uno non ha bisogno dell'altro, ma insieme lavorano nella stessa base dati.
anzi devo capire come impostare la Port ForWarDing qualcuno sa come si imposta in modo corretto?
Lo stai facendo?
Cliente -> Invia la domanda al database MYSQL-> Attende (timer)
Server -> Timer -> Legge la domanda da MYSQL, inserisce la risposta in MYSQL
Client -> Timer -> Legge la risposta da MYSQL
Quindi il client non parla con il server, ma con il database MYSQL
Il server non parla con il client, ma con il database MYSQL
Si utilizzano i timer per sincronizzare domande/risposte tra client e server
========
Are you doing this?
Client -> Sends question to MYSQL database-> Waits (Timer)
Server -> Timer -> Reads question from MYSQL, places answer into MYSQL
Client -> Timer -> Reads answer from MYSQL
So the client does not talk to the server, but to the MYSQL database
Server does not talk to the client, but to the MYSQL database
You use timers to synchronize question/answers between Client and Server
Cliente -> Invia la domanda al database MYSQL-> Attende (timer)
Server -> Timer -> Legge la domanda da MYSQL, inserisce la risposta in MYSQL
Client -> Timer -> Legge la risposta da MYSQL
Quindi il client non parla con il server, ma con il database MYSQL
Il server non parla con il client, ma con il database MYSQL
Si utilizzano i timer per sincronizzare domande/risposte tra client e server
========
Are you doing this?
Client -> Sends question to MYSQL database-> Waits (Timer)
Server -> Timer -> Reads question from MYSQL, places answer into MYSQL
Client -> Timer -> Reads answer from MYSQL
So the client does not talk to the server, but to the MYSQL database
Server does not talk to the client, but to the MYSQL database
You use timers to synchronize question/answers between Client and Server
Non so che dire, saro' duro io ma continuo a non capire
Un server che 'legge le domande ogni tot tempo' non si e' mai sentito
Capisco quello che stai descrivendo ma non c'e' nessuna ragione tecnica che sostenga questa scelta
Anzi ci sono molte ragioni per non adottare una strategia di questo tipo
E' chiaro che i vari client sono indipendenti dal resto, ma non e' questo il punto
Che cosa, esattamente, ti impedirebbe di far leggere-richiesta/memorizzarla/restituire-risposta al tuo server ogni volta che gli arriva una richiesta?
Che sostanzialmente e' quello che fanno tutti i server di questo mondo
Attansion che dal momento che al server arriva una richiesta, il numero di operazioni che puo' fare prima di restituire la risposta, deve poter essere di qualsiasi tipo
Nel senso che se al server arriva una domanda, deve poter fare operazione1, poi operazione2 poi operazioneN, e poi restituire la risposta
E se questa trafila durasse anche un'ora poco importerebbe, perche' se arrivassero 10 domande una dopo l'altra, ad ognuna verrebbe assegnato un id diverso e servite appena concluso il lavoro corrente, se la richiesta 1 arriva alle 00.00 verra' risposto alle 01.00, la seconda richiesta che e' arrivata alle 00.01 verra' identificata come ID 2 e verra' servita appena finito con la 1 e mettendoci un'ora di elaborazione la risposta all'id 2 verra' restituita alle 02.00, e cosi' via
Ti consiglio di studiare gli esempi di web server fatti in b4j, il lavoro da fare e' identico
Un server che 'legge le domande ogni tot tempo' non si e' mai sentito
Capisco quello che stai descrivendo ma non c'e' nessuna ragione tecnica che sostenga questa scelta
Anzi ci sono molte ragioni per non adottare una strategia di questo tipo
E' chiaro che i vari client sono indipendenti dal resto, ma non e' questo il punto
Che cosa, esattamente, ti impedirebbe di far leggere-richiesta/memorizzarla/restituire-risposta al tuo server ogni volta che gli arriva una richiesta?
Che sostanzialmente e' quello che fanno tutti i server di questo mondo
Attansion che dal momento che al server arriva una richiesta, il numero di operazioni che puo' fare prima di restituire la risposta, deve poter essere di qualsiasi tipo
Nel senso che se al server arriva una domanda, deve poter fare operazione1, poi operazione2 poi operazioneN, e poi restituire la risposta
E se questa trafila durasse anche un'ora poco importerebbe, perche' se arrivassero 10 domande una dopo l'altra, ad ognuna verrebbe assegnato un id diverso e servite appena concluso il lavoro corrente, se la richiesta 1 arriva alle 00.00 verra' risposto alle 01.00, la seconda richiesta che e' arrivata alle 00.01 verra' identificata come ID 2 e verra' servita appena finito con la 1 e mettendoci un'ora di elaborazione la risposta all'id 2 verra' restituita alle 02.00, e cosi' via
Ti consiglio di studiare gli esempi di web server fatti in b4j, il lavoro da fare e' identico
Yes, that is basically correct, the server is actually mysql, the server (b4j) is nothing more than a server of answers based on the list of questions that is found, its job is to take charge of the questions and generate the answers that are sent back to mysql.
The client ultimately does nothing but query and read the finished response or responses.
--------------------------------
Si fondamentalmente è corretto, il server in realtà e mysql, il server (b4j) non è altro che un servitore di risposte sulla base della lista domande che si trova, il suo lavoro e quello di prendersi a carico le domande e generare le risposte che vengono inviate di nuovo a mysql.
Il client alla fine non fa altro che domandare e leggere la risposta o le risposte finite.
allora non è un sito dove fai una richiesta e trovi la risposta esempio una "select * from table", chiaramente sarebbe inutile il mio progetto visto che http esiste da secoli ormai,
Facciamo esempio semplice la domanda potrebbe essere Cosa fai stasera? (la butto li e ti arriva su whatsapp tu la leggi e poi rispondi (credo sia corretto questo concetto) pertanto chi ti a scritto è il client e tu sei il server (per modo di dire) una semplice chat e fino qui credo sia oramai chiaro.
Nel mio caso funziona in questa maniera identica, il client scrive e il serve (so che è una parola sbagliata) ma non saprei come definirlo, prende in pasto la tua richiesta e ne da una risposta... come vedi nell'esempio precedente:
Q: Cosa fai stasera?
(s) intervallo temporale
A: esco e vado a cena dalla mia amante!!!!
(s) intervallo temporale
Q: Come si chiama?
(s) intervallo temporale
A: ma saranno cazzi miei!!!!
...
Tra le due azioni ( Scrittura (Q), lettura o intervallo temporale (s), risposta (A) ) quindi abbiamo un azione (s) che è quella di prendersi la domanda, leggerla, rispondere alla stessa, tutto questo, se lo vuoi automatizzare devi usare un timer o qualcosa del genere perché sono azioni che (s) fa in modo autonomo, a sua volta il client se vuole la risposta deve andare a leggersela, non posso tenerlo impegnato finché non rispondo la sua domanda, quindi lo libero.
A questo punto sarà compito del client a guardare quando la risposta è pronta e la legge, esattamente come si fa su chat o whastapp
"stasera me la dai" passano tre ore e ti scrive "NO", tu nel frattempo hai guardato la chat finché non arrivava la risposta.
Non posso dire di essere capito perché le idee non sono sempre chiare, se poi sono io ad esprimerle la cosa diventa ardua per tutti.
Comunque stavo facendo dei test con connessioni simultanee da 3 client sparsi per la casa che fanno query una ogni 10 secondi e per leggere le risposte create dal server (b4j mio che server non è) che legge il server mysql ogni secondo (non sarà così e solo un test di massacro e sto cercando di ottimizzare) che verifica se ci sono novità da elaborare e nel caso risponde alla questione, nessuna crisi, basso uso della cpu, ho connessioni basse ma a mio dire alte.
Mi connetto su ip (NOIP) remoto al pc di casa e non fa una piega.
Comunque stavo facendo dei test con connessioni simultanee da 3 client sparsi per la casa che fanno query una ogni 10 secondi e per leggere le risposte create dal server (b4j mio che server non è) che legge il server mysql ogni secondo (non sarà così e solo un test di massacro e sto cercando di ottimizzare) che verifica se ci sono novità da elaborare e nel caso risponde alla questione, nessuna crisi, basso uso della cpu, ho connessioni basse ma a mio dire alte.
Mi connetto su ip (NOIP) remoto al pc di casa e non fa una piega.
Scenario 1
Supponiamo, tanto per dire, che il server vada in cerca su ChatGpt delle risposte prima di restituirle
Allora il client A lancia una richiesta, il tuo server la identifica come id domanda =1 ed avvia il suo lavoro di ricerca della risposta in giro per il mondo, la connessione col client e' sempre 'in tiro', ed attendera' finche' arriva la risposta o finche un timeout fa desistere il client che chiudera' brutalmente la connessione
Quando il server avra' la risposta disponibile, che puo' essere anche dopo un'ora dalla richiesta id 1, se la connessione per id 1 e' ancora disponibile, allora la restituira'
Nel caso dopo un microsecondo dalla richiesta id 1 arrivasse un'altra richiesta dal client B, il server prendera' la seconda richiesta gli assegnera' id=2 e la mettera' in coda (perche' sta gia' serverndo la richiesta id 1)
Nel caso dopo un microsecondo dopo la richiesta id 2 arrivasse un'altra richiesta dal client C, il server prendera' la terza richiesta gli assegnera' id=3 e la mettera' in coda (perche' sta gia' serverndo la richiesta id 1)
Appena trovata (che puo' essere anche dopo un'ora) la risposta alla domanda id 1 il server la restituira' sulla connessione aperta dal client A e controllera' se ci sono altre richieste in coda, trovera' la richiesta id 2 ed id3, prendera' la piu' recente ed iniziera' la sua ricerca della risposta per id 2
E via di questo passo
Niente bisogno di timer
Scenario 2
Vuoi ottenere un sistema tipico di una chat, tanti client che sono collegati con un sistema centrale, il tuo server, da ogni client puoi voler scrivere ad un altro client o a tutti gli altri con un messaggio solo
In questo caso, se sono telefoni, inviare la richiesta da telefono a server non c'e' problema, il client si colleghera', spedira' il messaggio, e chiudera' la connessione col server, tanto non si dovra' attendere una risposta
Il problema e' come fare per restituire la risposta quando il server ce l'avra', che puo' essere un altro client che sta rispondendo al primo tre giorni dopo ad esempio
E qua non puoi usare una connessione tipo socket, dovresti tenerla sempre attiva e coi telefoni sta cosa e' poco fattibile
E li se vuoi comunicare da server/pc verso dispositivo remoto, a mio avviso c'e' solo Sms, Firebase, Mqtt
Scartando il primo per motivi di prestazioni (a volte un sms 'normale' arriva molto dopo l'invio) restano gli ultimi due
Ci sono molti esempi di chat sia Firebase che Mqtt sul forum, ti consiglierei di dare un'occhiata
Niente di sogno di timer
Non so se ho centrato gli esempi, volevo solo dire che sia col primo che col secondo non ci sarebbe bisogno di timer
Con questo non vorrei scoraggiarti dal realizzare un progetto che li utilizzi, ma volevo dire semplicemente che ci sono sistemi per non usarli, con benefici relativamente alle prestazioni dell'interno sistema (risposta inviata al singolo client esattamente appena e' disponibile)
Supponiamo, tanto per dire, che il server vada in cerca su ChatGpt delle risposte prima di restituirle
Allora il client A lancia una richiesta, il tuo server la identifica come id domanda =1 ed avvia il suo lavoro di ricerca della risposta in giro per il mondo, la connessione col client e' sempre 'in tiro', ed attendera' finche' arriva la risposta o finche un timeout fa desistere il client che chiudera' brutalmente la connessione
Quando il server avra' la risposta disponibile, che puo' essere anche dopo un'ora dalla richiesta id 1, se la connessione per id 1 e' ancora disponibile, allora la restituira'
Nel caso dopo un microsecondo dalla richiesta id 1 arrivasse un'altra richiesta dal client B, il server prendera' la seconda richiesta gli assegnera' id=2 e la mettera' in coda (perche' sta gia' serverndo la richiesta id 1)
Nel caso dopo un microsecondo dopo la richiesta id 2 arrivasse un'altra richiesta dal client C, il server prendera' la terza richiesta gli assegnera' id=3 e la mettera' in coda (perche' sta gia' serverndo la richiesta id 1)
Appena trovata (che puo' essere anche dopo un'ora) la risposta alla domanda id 1 il server la restituira' sulla connessione aperta dal client A e controllera' se ci sono altre richieste in coda, trovera' la richiesta id 2 ed id3, prendera' la piu' recente ed iniziera' la sua ricerca della risposta per id 2
E via di questo passo
Niente bisogno di timer
Scenario 2
Vuoi ottenere un sistema tipico di una chat, tanti client che sono collegati con un sistema centrale, il tuo server, da ogni client puoi voler scrivere ad un altro client o a tutti gli altri con un messaggio solo
In questo caso, se sono telefoni, inviare la richiesta da telefono a server non c'e' problema, il client si colleghera', spedira' il messaggio, e chiudera' la connessione col server, tanto non si dovra' attendere una risposta
Il problema e' come fare per restituire la risposta quando il server ce l'avra', che puo' essere un altro client che sta rispondendo al primo tre giorni dopo ad esempio
E qua non puoi usare una connessione tipo socket, dovresti tenerla sempre attiva e coi telefoni sta cosa e' poco fattibile
E li se vuoi comunicare da server/pc verso dispositivo remoto, a mio avviso c'e' solo Sms, Firebase, Mqtt
Scartando il primo per motivi di prestazioni (a volte un sms 'normale' arriva molto dopo l'invio) restano gli ultimi due
Ci sono molti esempi di chat sia Firebase che Mqtt sul forum, ti consiglierei di dare un'occhiata
Niente di sogno di timer
Non so se ho centrato gli esempi, volevo solo dire che sia col primo che col secondo non ci sarebbe bisogno di timer
Con questo non vorrei scoraggiarti dal realizzare un progetto che li utilizzi, ma volevo dire semplicemente che ci sono sistemi per non usarli, con benefici relativamente alle prestazioni dell'interno sistema (risposta inviata al singolo client esattamente appena e' disponibile)
Last edited:
Ciao Ivano
quello che vogliono semplicemente suggerirti e che potresti (dovresti) evitare di mettere di mezzo mysql tra server e client, in pratica il client non deve porre le sue domande salvandole su mysql ma inviarle al server e lui gestirle ed eventualmente sempre il server, salvarle insieme alla risposta su mysql per un riutilizzo immediato ad una successiva richiesta identica/simile.
Detto in parole povere
quello che vogliono semplicemente suggerirti e che potresti (dovresti) evitare di mettere di mezzo mysql tra server e client, in pratica il client non deve porre le sue domande salvandole su mysql ma inviarle al server e lui gestirle ed eventualmente sempre il server, salvarle insieme alla risposta su mysql per un riutilizzo immediato ad una successiva richiesta identica/simile.
Detto in parole povere
"...evitare di mettere di mezzo mysql tra server e client..."
Ah adesso ho capito perche' c'ha messo il timer, non avevo visto che i client scrivono sul db e poi il programma-server deve leggere da db
Si funzionare funziona anche, ma e' un sistema grandemente raffinabile
(si vede che volevo scrivere 'barbaro' poi ho evitato? no? meglio cosi)
I client devono 'parlare' col programma-server, poi se c'e bisogno di memorizzare/leggere sul db lo fara' sempre il programma-server
Al momento tutto regge, ottima sincronizzazione tra risponditore e client, i consumi sono bassi a mio dire e le connessioni al server non vanno oltre a 5
a sx (listview) le domande dei client
a dx (listview) le domande che hanno ricevuto la risposta dal risponditore
a dx in alto si vedono i timer che sincronizzano il lavoro da svolgere
considerando che uso NOIP per arrivare al mio pc dall'esterno, qui sotto vedete il tempo di raccolta automatica dal client, senza toccare nulla arrivano i dati raccolti con le domande e le risposte. (nel video faccio un reset delle risposte e dopo di che il risponditore le ricrea e le consegna)
MySql pannello di controllo
a sx (listview) le domande dei client
a dx (listview) le domande che hanno ricevuto la risposta dal risponditore
a dx in alto si vedono i timer che sincronizzano il lavoro da svolgere
considerando che uso NOIP per arrivare al mio pc dall'esterno, qui sotto vedete il tempo di raccolta automatica dal client, senza toccare nulla arrivano i dati raccolti con le domande e le risposte. (nel video faccio un reset delle risposte e dopo di che il risponditore le ricrea e le consegna)
MySql pannello di controllo
Last edited:
