Ciao a tutti vorrei chiedere 2 info sui timer quanti timer si possono gestire contemporaneamente senza influire sulle risorse del dispositivo o del pc?
-
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' troppo generica
Cosa vuol dire 'senza influire' ?
Anche con uno, influenzi le risorse pc, magari lo 0,01 % cpu va via per il nuovo timer aggiunto (magari e' anche meno ehhh, ho sparato a caso)
Voglio dire, definendo meglio la domanda, magari una risposta, quelli bravi, potrebbero anche darla
Noi siamo banda scarsotti, e quindi serviamo solo per fare un po' di confusione, ma gia' cosi' va bene
Da 2 a 5 timer che lavorano eseguendo queryDomanda interessante alla quale non ho risposta.
Comunque non credo che dei timer influiscano più di tanto.
Ma di quanti timer parliamo?
Può esserci una soluzione diversa?
Hai ragione ma non ho ancora ben chiaro il tutto, diciamo che i timer lavorano senza mai a fermarsi e generano azioni sulla base di quante richieste arrivano, ma ogni tot secondi fanno cicli di verifica e azione.
Credo che 5 timer siano ininfluenti, se non devi lavorare a millisecondi di precisione.
Ma perché timer?
Se devi attendere che le varie query siano complete meglio utilizzare dei WaitFor.
Ma non conosco il progetto quindi mi fermo quí.
Non andrebbe bene perché un wait finisce i timer continuano senza sosta, esempio ricevo 200 richieste in 24 ore devo monitorare ogni richiesta e rispondere in tempi immediati, quindi ogni tot secondi leggo tutte le possibili richieste e ad esse rispondo una ad una, il server mysql le inscatola e il client le legge. Quindi è un continuo flusso di scrittura e letturaCredo che 5 timer siano ininfluenti, se non devi lavorare a millisecondi di precisione.
Ma perché timer?
Se devi attendere che le varie query siano complete meglio utilizzare dei WaitFor.
Ma non conosco il progetto quindi mi fermo quí.
Stai litigando con questo e quello (UDP, MQTT, timer) mentre la soluzione migliore è un server websocket.
E' meno complicato di quanto si possa pensare e puoi trovare diversi esempi di Erel.
Usare i timer non solo incasina il codice, si rischia di perdere richieste ed altri problemi vari ma, soprattutto, costa in termini di consumo della batteria.
Cerca sul sito: websocket e/o webapp, filtrando per autore Erel e come categoria Tutorial.
Al limite, potrei prepararti una soluzione base, websocket client-server; sempre se mi offri (donazione) come minimo una pizza ? (ma vedrai che, come detto, troverai esempi di Erel che ti saranno utili).
Non ho ben capito una cosa, ma perche' ogni richiesta non la servi subito?
A che serve fare una temporizzazione che vada a verificare le richieste arrivate prima?
Fossi in te farei tutto al momento, arriva la prima richiesta, taaacc verifichi che vogliono e la servi
Arriva la seconda taaaccc verifichi che dicheno e la esegui
La terza, taaacccc...
A meno che il tuo programma che serve le richieste non sia spento quando le richieste arrivano
E quindi sei nell'ipotesi di avere un 'ricevitore' attivo h24 ed un 'servitore_richieste' attivo dalle 08 alle 12 per esempio
in effetti fa così
dammi dei riferimenti e poi sarai onorato... a modo mio ovviamente
Ok, supponiamo che tuo programma A, attivo dalle 08.00 alle 18.00, vada a leggere dei file di testo (per fare un'esempio) che il programma B, attivo h24, ha ricevuto
Il programma andra' a leggere un file e lo servira', se disponibili altri file li leggera' uno alla volta e li servira'
Finito di eseguire i comandi nei file disponibili, si mettera' in attesa di esentuali altri file che arrivassero e li servira', un qualcosa tipo FileObserver o simile
Il timer, a che serve?
interessante e non è detto che non venga utilizzato ma faccio chiarezza sul mio progetto:
1) server: una software che prende a carico domande e genera le risposte, le domande hanno dei riferimenti ben precisi che verranno poi modificati, esempio (domanda senza risposta, gruppo di appartenenza, ecc ecc
2) tutte le richieste vengono memorizzate su database (ho scelto mysql visto che è il più utilizzato per lato web)
3) client: invia richiesta (ogni richiesta è completa di id client, gruppo, ect ect) e attende risposta e viene memorizzata su database (mysql)
tutto abbastanza semplice
quindi abbiamo un progetto basato su client che non fa altro che domandare e leggere le risposte, un server che non fa altro che prendersi a carico le domande e generare le risposte e un database che non fa altro che memorizzare ogni dato
client è uno a molti (android, ios, mac, linux, windows)
server è uno (windows, mac, linux)
database è uno (mysql)
Su base velocità del server mysql e stabile, scalabile e veloce è può memorizzare infiniti mb di dati
Il server ho notato che può essere veloce ma non deve essere troppo veloce visto che molte risposte arrivano dal web
il client deve essere semplice e minimalista
ho notato che UDP come scriveva anche @LucaMs non è affidabile per i pacchetti che si possono volatilizzare e cmq ha limiti già per se anche se poi viene usato per tanti prodotti stream, MQTT sembra andare bene ma anche lui richiede attenzioni non indifferenti, IO non ho tutta questa base di conoscenza e quindi mi dovrei affidare a persone esterne cosa che non amo molto essere dipendente.
da qui mi sono posto una domanda, ma se usi mysql come base dati e cmq un server riceve e invia risposte ha dei timer che fanno leggere e scrivere o fanno azioni ben precise cosa mostruosa che io al momento non necessito perchè non usare i timer che in modo preciso e sincronizzato mi fanno il lavoro sporco di leggere e scrivere?
Da qui nascono le domande
i timer influiscono molto?
quanti timer posso usare o mi servono? (su client 2) , (sul server 3/5), pare ovvio che poi le risorse che userò fanno la differenza su l'uso della memoria del pc e non sul client che domanda e legge la risposta. qui sotto metto un disegno idea.
Ora visto che mysql esitono anche i trigger (Il trigger MySQL è un oggetto di database che è associato ad una tabella. Sarà attivato quando un’azione predefinita viene eseguita per la tabella. Il trigger può essere eseguito quando esegui uno dei seguenti statement MySQL sulla tabella: INSERT, UPDATE e DELETE. Può essere richiamato prima o dopo l’evento.) da qui mi sono detto, potrei sfruttare il motore MYSQL come server dati che mi muove le app client e server.
Ecco perché la domanda iniziale.
Daje co 'sti timer
Ma qual'e' la necessita' di usare dei timer per fare quel che vogliamo fare?
Se Web/MySql/Server saranno accesi immagino h24 (perche' se hai dei client che 'domandano' su internet credo sia naturale che la zona 'server' sia sempre disponibile) a che te servono sti timer?
Qual'e' il motivo esatto per cui non puoi servire le richieste in realtime?
Arriva la prima, leggi, cerchi, rispondi, taaacccc...
Alla seconda leggi, cerchi, rispondi, taaaaccc..
E via cosi di taaaccc
Ma qual'e' la necessita' di usare dei timer per fare quel che vogliamo fare?
Se Web/MySql/Server saranno accesi immagino h24 (perche' se hai dei client che 'domandano' su internet credo sia naturale che la zona 'server' sia sempre disponibile) a che te servono sti timer?
Qual'e' il motivo esatto per cui non puoi servire le richieste in realtime?
Arriva la prima, leggi, cerchi, rispondi, taaacccc...
Alla seconda leggi, cerchi, rispondi, taaaaccc..
E via cosi di taaaccc
ora con 2 timer client e 2 sul server vedo che non fa una piega, lavora bene e non sforza nulla con mysql e due query riesco a fare tutto a parte qualche cagata di query che ancora devo perfezionare.
lato sx il client legge
lato dx il serve rimane in attesa di una domanda e quando la riceve la prende in carico e risponde
non è ancora impaginato come dovrebbe cosa che faccio alla fine, ma sono già soddisfatto, se tutto va ok la versione mobile e molto più semplice di prima.
Ringrazio @Star-Dust chi mi ha dato assistenza con la sua libreria SD_MYSQL in questo momento tutto procede come mi ero proposto con meno timer 1 solo per client e 2 solo per il server e riesco a manovrare più client e il server mysql, le risposte sono quasi immediate anche se devo migliorare la struttura delle query ma tutto va come volevo.sto simulando con un robot query su query sperando di non vedere crash e di vedere il consumo energetico e di ram che ad ora è molto basso.
non capisco la domanda scusami,
tutto è in realtime vale a dire che avendo più client che fanno domande il server (mio) che è in ascolto attraverso timer risponde a tutte le domande in coda, una ad una, poi ogni client legge le sue risposte o le risposte o le risposte del gruppo
il problema che avevo prima che avendo dichiarato una variabile mysql troppe richieste nella stessa variabile (anche solo 2) si andava a innescare un conflitto e quindi crash, avendo creato una classe ad ogni richiesta a mysql istanzio la classe e la uccido subito dopo, quindi potrei fare 1000 richieste istanziando 1000 volte la classe stessa, in questo caso non avrei problemi
Anche se da dire che al momento le casistiche si fermano a tre istanze (inser, select, update)
Spero di aver capito la tua domanda.
Via Google Translate:
Continuo a non capire la necessità di timer. Nessuno degli strumenti forniti da B4X, sia per le connessioni UDP, TCP o HTTP, richiede timer affinché un programma si renda conto che le informazioni sono state inviate da un client a un server. In tutti i casi, viene generato un evento che può quindi essere utilizzato per elaborare le informazioni. Perché non dai un'occhiata al server FTP implementato in B4X. Non richiede timer e può gestire le richieste dei clienti in tempo reale senza sudare.
Original:
I still don't understand the need for timers. None of the tools that B4X provides, be it for UDP, TCP or HTTP connections require timers in order for a program to realize that information was sent from a client to a server. In all cases, an event is raised that can then be used to process the information. Why don't you take a look at the FTP server that is implemented in B4X. It requires no timers and can handle client request in real-time without breaking a sweat.
www.b4x.com
Continuo a non capire la necessità di timer. Nessuno degli strumenti forniti da B4X, sia per le connessioni UDP, TCP o HTTP, richiede timer affinché un programma si renda conto che le informazioni sono state inviate da un client a un server. In tutti i casi, viene generato un evento che può quindi essere utilizzato per elaborare le informazioni. Perché non dai un'occhiata al server FTP implementato in B4X. Non richiede timer e può gestire le richieste dei clienti in tempo reale senza sudare.
Original:
I still don't understand the need for timers. None of the tools that B4X provides, be it for UDP, TCP or HTTP connections require timers in order for a program to realize that information was sent from a client to a server. In all cases, an event is raised that can then be used to process the information. Why don't you take a look at the FTP server that is implemented in B4X. It requires no timers and can handle client request in real-time without breaking a sweat.
[B4X] FTP Server implemented with Socket and AsyncStreams
(Note that the FTP client above is not part of this solution. It only demonstrates how you can use a standard FTP client to communicate with the server.) This is an example of using low level network features to implement a high level protocol. It is an implementation of a standard FTP server...
www.b4x.com
