Ciao a tutti.
Il server che ci ospita sta facendo le bizze per cambio gestione ed e' diventato inaffidabile.
Ergo, stiamo trovando altra collocazione. Temporaneamente, ritrasferiremo il tutto in sala macchine a Polcenigo, anche se la connettività non è certo di 2MBit simmetrici :)
Tempo di individuare un server virtuale che ci consenta quel minimo di servizi ad un prezzo onesto.
lunedì 12 maggio 2008
domenica 24 febbraio 2008
Release 1.0.14.1
C'e' voluto un bel po' di rivisitazioni. In effetti la gestione UDP realizzata precedentemente aveva dei problemi.
Ora l'UDP e il discovery in rete locale sembra funzionare abbastanza bene.
Idem l'upchannel udp verso il server. Non abbiamo ancora testato il canale udp di ritorno.
Restano da sperimentare le risposte implicite udp.
Dovrebbe essere attivabile anche il canale UDP verso i client (subnets) ma anche questo non ancora testato. Dovrebbe essere sufficente aprire la vostra porta verso l'esterno.
Le connessioni UDP vengono testate dopo l'apertura di un canale TCP tra i client, quindi se non funziona il primo, non andrà il secondo.
Ci sono delle nuove scritte sulla gui, ve ne do un sunto.
Reactive: e' aperto il canale in ingresso TCP = vi possono raggiungere dall'esterno con connessioni dirette
Furious: e' aperto e confermato il canale in ingresso UDP = idem come sopra, ma udp
Carrier udp tx: e' stato confermato che il server vi riceve in UDP, per cui l'invio dati avverrà in udp.
Nonostante altri problemi da sistemare, ora mi butto a implementare una feature nuova.
Se ci riesco in un'ora la pubblico.
Saluti.
Ora l'UDP e il discovery in rete locale sembra funzionare abbastanza bene.
Idem l'upchannel udp verso il server. Non abbiamo ancora testato il canale udp di ritorno.
Restano da sperimentare le risposte implicite udp.
Dovrebbe essere attivabile anche il canale UDP verso i client (subnets) ma anche questo non ancora testato. Dovrebbe essere sufficente aprire la vostra porta verso l'esterno.
Le connessioni UDP vengono testate dopo l'apertura di un canale TCP tra i client, quindi se non funziona il primo, non andrà il secondo.
Ci sono delle nuove scritte sulla gui, ve ne do un sunto.
Reactive: e' aperto il canale in ingresso TCP = vi possono raggiungere dall'esterno con connessioni dirette
Furious: e' aperto e confermato il canale in ingresso UDP = idem come sopra, ma udp
Carrier udp tx: e' stato confermato che il server vi riceve in UDP, per cui l'invio dati avverrà in udp.
Nonostante altri problemi da sistemare, ora mi butto a implementare una feature nuova.
Se ci riesco in un'ora la pubblico.
Saluti.
sabato 23 febbraio 2008
Udp transactions
Ci ho provato, non e' una resa ma un tentativo. In condizioni di rete come quelle di Polcenigo, si verificano spesso buchi e salti nella comunicazione audio, come se, a meno che non ci siano errori nella nostra implementazione, effettivamente i pacchetti TCP non garantiscano un fusso costante dei dati.
Ricordo comunque che in ambienti non internet-wireless (modena adsl, ad esempio) le cose non sono affatto cosi' tragiche.
Ad ogni modo, abbiamo implementato parallelamente al flusso dati di controllo tcp, l'invio e ricezione audio UDP, senza controllo di sequenza. Stiamo a vedere che succede.
Dettagliuccio. Per ora, nel momento in cui sarà aperta la porta sul server (ndr), la connessione udp e' solo in uscita. Perche' lo sia anche in ingresso bisogna aprire il routing per UDP oltre che UDP sulla porta specificata nelle preferenze. I due ultimi check devono essere tutti e due attivi.
Il passo successivo e' implementare il "point to point" reale, sfruttando i vari trucchetti documentati in rete.
Ah, nelle reti locali, non c'e' problema tutto l'audio dovrebbe andare in UDP senza problemi.
Ricordo comunque che in ambienti non internet-wireless (modena adsl, ad esempio) le cose non sono affatto cosi' tragiche.
Ad ogni modo, abbiamo implementato parallelamente al flusso dati di controllo tcp, l'invio e ricezione audio UDP, senza controllo di sequenza. Stiamo a vedere che succede.
Dettagliuccio. Per ora, nel momento in cui sarà aperta la porta sul server (ndr), la connessione udp e' solo in uscita. Perche' lo sia anche in ingresso bisogna aprire il routing per UDP oltre che UDP sulla porta specificata nelle preferenze. I due ultimi check devono essere tutti e due attivi.
Il passo successivo e' implementare il "point to point" reale, sfruttando i vari trucchetti documentati in rete.
Ah, nelle reti locali, non c'e' problema tutto l'audio dovrebbe andare in UDP senza problemi.
domenica 17 febbraio 2008
Intranet discovery
Chiarisco una caratteristica. Ogni client cerca, tramite messaggi broadcast, altri client tilimi sulla rete locale.
Nel momento in cui vengono trovati, saranno possibili connessioni dirette: il che vuol dire che il sw puo' essere usato come un interfono, senza che i dati passino dal server centrale.
La ricerca viene fatta da ogni client, periodicamente, durante il funzionamento. Se qualcuno vede pacchetti broadcast sulla propria rete interna su porta UDP 11345 non si allarmi.
E' altrettanto ovvio che se ci sono dei firewall locali sui singoli pc, questo meccanismo non funzionerà.
Saluti
Nel momento in cui vengono trovati, saranno possibili connessioni dirette: il che vuol dire che il sw puo' essere usato come un interfono, senza che i dati passino dal server centrale.
La ricerca viene fatta da ogni client, periodicamente, durante il funzionamento. Se qualcuno vede pacchetti broadcast sulla propria rete interna su porta UDP 11345 non si allarmi.
E' altrettanto ovvio che se ci sono dei firewall locali sui singoli pc, questo meccanismo non funzionerà.
Saluti
Release 1.0.12.2
Ciao.
Abbiamo messo in linea il client 1.0.12.2, con aggiornamento non ancora mandatory. Il server è anche aggiornato con questa versione. Ci sono alcune modifiche lato client che documenterò, magari nella 1.0.13. Una di queste potrebbe migliorare la ricezione audio in modo sensibile.
Ci siamo accorti solo ora che per una serie di ragioni veongono inviati e propagati singoli pacchetti TCP di 96 byte con codifica gsm. I pacchetti cosi' piccoli, essendo una trentina al secondo, in condizioni di rete non ottimali, provocano ritardi e blocchi temporanei per l'handshake tcp necessario.
Ora, i pacchetti audio sono raggruppati in blocchi da 1400 bytes circa, per rientrare comunque nella dimensione dell MTU. La cosa è ragionevole porti miglioramenti. Ora i pacchetti in uscita ed in ricezione sono di 1400 bytes, circa 2 al secondo e non 30 da 96 bytes. L'aggiornamento del server implicitamente opera il raggruppamento sui dati inviati dai client precedenti. Stiamo a vedere.
Ci sarebbe da verificare se il limite di 1400 sia effettivamente vantaggioso o piuttosto conviene passare a 3000, anche se la latenza, sommata alle altre intrinseche nel sw diventa importante.
Stiamo ancora tergiversando prima di integrare anche trasmissioni UDP (connectionless). La strategia half-duplex ci permette di abusare di tcp e di non rendere importanti i ritardi di trasmissione per gli ack di protocollo.
Inoltre, nella lista delle cose importanti c'e' l'audio packet routing point to point, pronto ad essere implementato, non appena i canali point to point risultano stabili.
Ricordo che fino a questo momento, le trasmissioni PTP vengono utilizzate solo se dal "trasmittente" si possono vedere tutti i partecipanti con una connessione tcp diretta o inversa: in una conversazione tra 2 persone, almeno uno deve avere il firewall che mappa la porta di ingresso.
La porta di ingresso per le connessioni PTP e' impostabile (dal client precedente .1) a piacimento, ossia, se avete 3 client in una rete locale, potete aprire 3 porte esterne, ognuna che mappa sul rispettivo client. Il server COMUNQUE fa una verifica dopo il login sulla "raggiungibilità" del client dall'esterno, e la comunica al resto degli utenti, per cui anche lasciando attivata erroneamente la porta di ingresso non ci dovrebbero essere problemi.
Saluti.
Abbiamo messo in linea il client 1.0.12.2, con aggiornamento non ancora mandatory. Il server è anche aggiornato con questa versione. Ci sono alcune modifiche lato client che documenterò, magari nella 1.0.13. Una di queste potrebbe migliorare la ricezione audio in modo sensibile.
Ci siamo accorti solo ora che per una serie di ragioni veongono inviati e propagati singoli pacchetti TCP di 96 byte con codifica gsm. I pacchetti cosi' piccoli, essendo una trentina al secondo, in condizioni di rete non ottimali, provocano ritardi e blocchi temporanei per l'handshake tcp necessario.
Ora, i pacchetti audio sono raggruppati in blocchi da 1400 bytes circa, per rientrare comunque nella dimensione dell MTU. La cosa è ragionevole porti miglioramenti. Ora i pacchetti in uscita ed in ricezione sono di 1400 bytes, circa 2 al secondo e non 30 da 96 bytes. L'aggiornamento del server implicitamente opera il raggruppamento sui dati inviati dai client precedenti. Stiamo a vedere.
Ci sarebbe da verificare se il limite di 1400 sia effettivamente vantaggioso o piuttosto conviene passare a 3000, anche se la latenza, sommata alle altre intrinseche nel sw diventa importante.
Stiamo ancora tergiversando prima di integrare anche trasmissioni UDP (connectionless). La strategia half-duplex ci permette di abusare di tcp e di non rendere importanti i ritardi di trasmissione per gli ack di protocollo.
Inoltre, nella lista delle cose importanti c'e' l'audio packet routing point to point, pronto ad essere implementato, non appena i canali point to point risultano stabili.
Ricordo che fino a questo momento, le trasmissioni PTP vengono utilizzate solo se dal "trasmittente" si possono vedere tutti i partecipanti con una connessione tcp diretta o inversa: in una conversazione tra 2 persone, almeno uno deve avere il firewall che mappa la porta di ingresso.
La porta di ingresso per le connessioni PTP e' impostabile (dal client precedente .1) a piacimento, ossia, se avete 3 client in una rete locale, potete aprire 3 porte esterne, ognuna che mappa sul rispettivo client. Il server COMUNQUE fa una verifica dopo il login sulla "raggiungibilità" del client dall'esterno, e la comunica al resto degli utenti, per cui anche lasciando attivata erroneamente la porta di ingresso non ci dovrebbero essere problemi.
Saluti.
lunedì 4 febbraio 2008
Problema login multiplo
Oggi il sistema e' stato down per diverse ore, bloccato dopo un down di rete, nel tentativo di completare le sequenze di login dei vari clients aperti da tutti gli utenti.
Una inconsistenza nelle tempistiche client-server nella sequenza di login produceva il problema, oggi e' emerso in modo particolare; i giorni precedenti, con meno clients collegati, lo sblocco del sistema avveniva automaticamente dopo un certo tempo.
Ora dovrebbe essere risolto alla radice. Attendiamo una verifica domani, dove nel pomeriggio di solito ci sono svariati clients aperti.
Una inconsistenza nelle tempistiche client-server nella sequenza di login produceva il problema, oggi e' emerso in modo particolare; i giorni precedenti, con meno clients collegati, lo sblocco del sistema avveniva automaticamente dopo un certo tempo.
Ora dovrebbe essere risolto alla radice. Attendiamo una verifica domani, dove nel pomeriggio di solito ci sono svariati clients aperti.
Ciao a tutti
Ciao a tutti.
Inauguro questo blog, in italiano, sulla costruzione del sistema Tilimi.
Sono benvenuti i commenti costruttivi.
Lo sviluppo e' ora lasciato alla libera fantasia degli autori, con un percorso di inserimento features non prestabilito.
L'obiettivo attuale e' di uscire dallo stadio beta di sviluppo, per promuovere il prodotto ad un pubblico ampio.
Ora come ora e' necessaria la vostra cooperazione per utilizzare al meglio il sistema.
Lucio Cosmo
Inauguro questo blog, in italiano, sulla costruzione del sistema Tilimi.
Sono benvenuti i commenti costruttivi.
Lo sviluppo e' ora lasciato alla libera fantasia degli autori, con un percorso di inserimento features non prestabilito.
L'obiettivo attuale e' di uscire dallo stadio beta di sviluppo, per promuovere il prodotto ad un pubblico ampio.
Ora come ora e' necessaria la vostra cooperazione per utilizzare al meglio il sistema.
Lucio Cosmo
Iscriviti a:
Commenti (Atom)