La situazione continua ad evolversi. Alcuni problemi si risolvono ed altri arrivano.
Sono riuscito a far funzionare il websocket php ben fatto trovato su github, e devo dire che è fatto fortuitamente bene.
Riesce anche a rilevare in tempo reale le deconnessioni su ogni browser, risolvendo parecchi dei problemi citati in precedenza.
E gestisce già la segmentazione del messaggio in frame, concatenandoli prima di passarli alla collback. Non so come cazzo funziona, ma so che funziona, quindi bella!

Purtroppo non è perfetto. Anche all’interno del codice si può trovare qualche //TODO che indica dei problemi da risolvere.
E ora il problema è che se un client prova ad inviare un messaggio molto lungo, dopo la trasmissione potrebbe disconnettersi. Dico potrebbe perché in effetti succede circa una volta su 10, e non mi è chiaro il motivo.

Lato server c’è un controllo all’interno dell’header del messaggio che verifica se il client ha inviato il flag per disconnettersi (non so che cazzo sia). E a volte questo controllo restituisce true, e il client viene forzatamente disconnesso dal server.

In ogni caso adesso riesco a inviare messaggi lunghi e riceverli lato server interi, e poi re-inviarli al client e fare un console.log del messaggio intero in un solo colpo.
Very GOOD!

Devo risolvere la deconnessione random e poi sono a posto, risolti tutti i problemi noti del WebSocket fatto in php. Potrebbe essere sufficiente intercettare lato client la deconnessione, ed eventualmente riconnettersi (con messaggio DRAG di init). Vedremo. Farò questo test, ed un test sulla lunghezza massima di un messaggio che posso inviare ricevendolo sia lato client che lato server tutto intero.

Spero che non ci sia da ricominciare tutto questo travaglio in Node.JS.

voila trovato il problema di trasmissione. il protocollo websocket spezzetta la trasmissione in frame quando i dati da inviare sono parecchi. ma non mi è chiara 1 il perché e 2 il come.
il primo frame è sempre da 128k, quindi credo che quando hai più dati da inviare di 128k inizia la divisione in frame, ma poi gli altri possono avere altre dimensioni.
tipo io col mio schermo pocciando al massimo tutto lo spazio disponibile, con tanto info casuali, colori e linee, sono arrivato a dover trasmettere circa 900k (porco dio!! per salvare un solo disegno cazzo! e col mio schermo del portatile, che non è di certo un 4k. il db dovrà essere bello capiente)
e lato server ho ricevuto un frame da 128k
uno da circa 500k
e un terzo coi restanti 300k.
quindi sta a me scoprire tramite gli header che ci sono nei frame che ricevo, se si tratta di un messaggio completo o di un pezzo. ed allora concatenare.
se non ho capito male, il grosso websocket php che ho trovato su github gestisce già questa cosa, ma non riesco a farlo funzionare ed ho guardato poco il codice. mi tocca studiarmi un po l’argomento.
e spero che in nodejs tutta questa roba sia facile.

ovviamente anche lato client ho lo stesso problema. il php invia una stringa json_encode del mia mega oggetto, e lato client mi ritrovo solo una parte della stringa se è troppo lunga. quindi il json.parse ovviamente fallisce visto che il json non è completo.
spero almeno che i frame arrivino in ordine, se no sono cazzi amari.

il server può inviare al client di sicuro ben più di 256 caratteri. ma non so che cazzo di leader bisogna dargli. ho visto che fino a 65000 caratteri funziona, perché il pocket che ho trovato gestiva già tutti i casi.
ma il caso con msg.length > 65000 in realtà non funziona.
ed è un argomento su cui si trova difficilmente googlando.

poi ho pensato che in effetti il server definitivo farebbe bene a spezzare le trasmissioni, tipo inviare massimo 3 disegni alla volta, perché in effetti se fai drag con molto zoom indietro e visualizzi i disegni solo quando li hai ricevuti tutti…. sticazzi.
ma questo dettaglio lo cagheremo solo col server vero fatto in node. non ha senso farlo sia ora in php che poi di nuovo in node.

ho trovato un altro codice di un websocket php, e questo è fatto con molte più funzioni e controlli, quindi mi studio il codice (500 righe porco dio) e cerco la soluzione che mi serve.
in pausa sfrutto la wifi del centro commerciale qui vicino e mi ci metto per mezzora

e vorrei mettere su il sito. appena il socket funziona compro il virtual server base di netsons, ci installo php mysql e lo faccio funzionare online. ma per questo devo anche pensare ad un nome dominio.
che nome ci starebbe bene? pensaci per favore e fammi sapere. social.art mi piace, ma non so come trasformarlo in un dominio. o prendo socialart.it .com .me .io , o cambio proprio il nome

intanto lo partorisco online in php (e sarà interessante avere un server remoto da configurare a mano, mai fatte ste cose), poi ci sarà la versione node in attesa. ma per ora preferisco andare avanti con la parte social del progetto.
sviluppare l’onclick sul svg in trasparenza e un login utente usando Facebook e google. così posso creare una pagina base per gli utenti.

ho scoperto altre cazzate sul ws php.
io le scrivo, tanto per prendere appunti, magari ti sono utili, magari non te ne frega un cazzo.

Safari:

– per ogni nuovo tab il server rileva un nuovo client => ok
– su refresh il server elimina il vecchio client e aggiunge il nuovo => ok
– se chiudo un tab il server elmina il client senza errori => ok

Chrome:

– per ogni tab, il server crea un client => ok
– su refresh, il server crea un nuovo client ma non elimina il vecchio => KO
– dopo qualche minuto dal refresh, il server riceve la notifica di chiudere il vecchio client => KO
– se si chiude un tab, il server perde il client troppo presto e logo 2 Warning => quasi ok, risolvo in php

Firefox:

– per ogni tab, il server crea un client => ok
– su refresh, il server crea un nuovo client ma non elimina il vecchio => KO
– dopo 20 secondi dal refresh, il server riceve la notifica di chiudere il vecchio client => KO
– se chiudo un tab, dopo 20 secondi il server riceve la notifica di chiudere il client => KO ma porco dio dai! (ma senza warning php)

IE:

– chissenefrega => OK!

RISULTATO:

Ma che cazzo! si dice che i browser supportano i WS ma in realtà tutti fanno ciò che vogliono.
beh poco male. tanto si parla di php, ed abbiamo già elencato una sacco di motivi per cui non lo useremo.
nella pratica questo impedisce di fare gli aggiornamenti in tempo reale vedendo comparire in diretta i disegni che gli altri stanno facendo proprio dove sei tu. ma chissenefrega, non è una funzione di primaria importanza ora. per ora userò il pocket solo per le due cose che potevo fare anche con ajax normale (salvataggio e recupero disegni), ma col vantaggio che trasferisco meno dati grazie al protocollo ws. praticamente risponde solo alle chiamate che riceverà dai client, di tipo “SAVE” o “DRAG”

e intanto mi ritrovo già queste due funzioni implementate lato client come ws e non ajax, e quando ci sarà un server serio con node basterà aggiornare il parametro dell’url e tutto funzionerà uguale.

social art l’ho sempre voluto fare in modo più modulabile possibile.
anche se il codice js è tutto dentro ad un unico file (…. -.-” …) ho organizzato tutto a moduli e configurazioni, in modo da usare delle api che ogni modulo mette a disposizione dell,altro.
cosi andare a fare una modifica mi costa sempre poco.

anche per le chiamate backend è lo stesso.
lato client ogni modulo sa come gestire il socket automaticamente, e a me nel js basta sapere l’url da chiamare.

ora la priorità è arrivare più in fretta possibile al parto, cioè tutto che funziona online appoggiandosi ad un backend php mysql. e se continuo di questo passo, arrivo ad avere una versione funzionante (che trascura completamente la sicurezza dei dati) nel weekend, salvo per un dubbio. per lanciare quel file devo lanciare una linea di comando php a terminale, e non so se si possa arrivare allo stesso risultato agli host del cazzo che ho io su netsons, che puoi gestire solo tramite cpanel.
quindi mi sa che per il parto dovrò in ogni caso comprare un vps. il base è 10 euro al mese.
e intanto ci metto su il backend php.
poi prima cosa da fare dopo il parto e farlo evolvere. e si passa a node.
cazzo che figata deve essere la gestione degli eventi che mi dici. vorrei conoscerla bene.

e post node, si passa a creare la parte utenti, ma quella dovrebbe essere relativamente facile.
una sola cosa sara difficile, cioè recuperare l’immagine su cui si ha effettivamente fatto click, considerando che si potrebbe aver fatto click su un px trasparente, e in quel caso devo prendere l’immagine sotto.

è la più grande difficoltà tecnica che rimane, tant’è che non so nemmeno se sarà fattibile, o se sarà necessario convertire tutta la dashboard in un altro canvas, e convertire il problema nella gestione dei layer di ogni disegno.

– socket node
– click trasparenza svg
– geotag della dashboard

Pat però promettiamoci una cosa.
se ci trovassimo nel caso in cui questo progetto inizia a prendere piede ed essere usato dalla gente, ci concediamo una possibilità. vieni a parigi e passiamo un anno a lavorare solo su questo :D
io giuro qui e ora che lavoro come dipendente solo finche social art non sarà in piedi, e se inizia a diffondersi mollo tutto e mi lancio. se la cosa funziona non ci sarà più bisogno di lavorare per avere soldi.

Non mi concentravo cosi tanto su social art da parecchio tempo, ed ora rispetto a 2 anni fa ho imparato che veramente fatto è meglio che perfetto. e sto procedendo velocemente.
2 anni fa non avrei mai accettato di partire con un pocket php solo perché non sapevo farlo in node. sarei rimasto a sbattere la testa per imparare una cosa nuova e farlo bene al primo colpo.
ora mi rendo conto che in ogni caso è meglio arrivare a mostrare qualcosa, piuttosto che non finire mai.
non vedo l’ora di mettere online una versione multiutente :D

è un po incasinato il socket php, ma direi che ne posso uscire facilmente.
ora ho il problema che non funziona più il riconoscere la deconnessione di un client, quindi ho un array di client a cui scrivere più altro del normale, e mi aspetto risposte che non arrivano.

comunque salvo nel db mysql via socket il base64 dell’immagine png e restituisco al client che me lo ha inviato l’id generato nel db.
per completare il salvataggio devo anche inviare quel nuovo disegno a tutti i client che sono nelle sue stesse coordinate.

ora devo fare il drag… significa che su ogni drag devo pushare le coordinate attuali, e lato server farmi un dizionario di client e relative coordinate. aggiornarle su ogni push dei client, ed eliminarli quando si disconnettono. e ad ogni push inviare il son di immagini.

purtroppo qui viene fuori il limite di php, che non è asincrono per natura come node.
il socket funziona grazie un while true…. ed ho detto tutto. quindi se faccio un drag, e devo inviare 10 disegni in json, potrebbe arrivarmi un’altro push per il drag successivo prima di aver finito la trasmissione dei dati del drag precedente. e non credo ci sia un modo per identificare il drag successivo e interrompere il precedente, visto che è tutto sincrono. in più il tempo di attesa tra la risposta di un drag e del successivo si somma per ogni client in parallelo….

la logica è :

while true
– prendi array di client connessi
– per ogni client guarda se c’è un messaggio
– se il messaggio è un disegno da salvare, lo salvo, e per ogni client connesso verifico le coordinate ed eventualmente lo invio
– se il messaggio è di tipo drag, aggiorno le coordinate, query sul db e invio il json di disegni (che può essere molto pesante….)

se ho 100 client connessi che esplorano la lavagna, rispondo ad uno alla volta. e un client che fa due drag di fila si beccherà due risposte, anche se la prima non serve piû a un cazzo, e per attendere la seconda (quella buona) dovrà aspettare che abbia risposto una volta a tutti gli altri 99 socket.

senza contare poi che php gira su un solo thread, quindi avere while true ti porta un core al 100% e ignora completamente tutti gli altri, usando solo una piccola parte della potenza di calcolo di un server.
quindi per far girare questo backend in php piuttosto che node, a parità di prestazioni bisogna spendere più soldi il server su netsons… per prendere più potenza di calcolo.

e non ho ancora idea di cosa accada se tra un ciclo e l’altro del while, lo stesso client ha mandato più di un messaggio… test ancora da fare