Le risposte a EXISTS, LASTSAVE, LLEN ecc. rendono difficile il parsing bulk delle risposte

[GoogleCodeExporter]

Mi sbaglierò, ma il modo con cui viene risposto ai comandi EXISTS,
LASTSAVE, LLEN ecc. rende un po' complicato fare il parsing delle risposte
bulk, slegato dalle richieste.

MI spiego meglio: le risposte del server sono di tre tipi (almeno per
quanto ho capito fino ad ora)

* una risposta che inizia con uno status +XXX (PING, SET)

* una risposta di errore che inizia con uno status -XXX

* una risposta numerica

* una risposta contenente uno o più valori

Nei primi due casi il primo carattere della prima riga definisce cosa
contiene il resto della risposta e in quante righe.

Negli altri due no, nel senso che una risposta in cui la prima riga
contiene un numero può avere un seguito (valori delle chiavi), o no (EXISTS
ecc.).

A questo punto fare un peek nel resto dei dati diventa problematico se il
socket è in blocking mode, se non c'è niente da leggere (EXISTS) si resta
appesi.

Sembra che l'unico modo di discriminare tra i due tipi di risposte sia
quindi di portarsi dietro la cronologia delle richieste e usare queste per
capire che tipo di formato ha la risposta. Non sarebbe più semplice
differenziare i due tipi di risposte (valore numerico su una riga come
unico contenuto, e valori su più linee con lunghezza del payload sulla
prima riga), in modo da svincolare completamente richieste e risposte nel
client? Poi è ovvio che se chi lo utilizza fa una richiesta non-bulk
riceverà subito la risposta, per richieste bulk dovrà invece fare il
matching da solo tra richieste e risposte, ma tanto deve farlo comunque è
intuile quindi farlo due volte (nel client per capire che formato ha la
risposta, e nel codice che lo usa per ricomporre richieste e risposte).

Metto in pausa il client python finchè non mi dai un parere. Può anche
darsi che io sia completamente off topic, non sarebbe la prima volta. :)

BTW già che ci siamo, una richiesta di esempio su come impostare una lista
nel doc ci starebbe bene, non è proprio immediato da capire.

Original issue reported on code.google.com by ludovico...@siassb.eu on 26 Feb 2009 at 2:59

[GoogleCodeExporter]

"sono di tre tipi" ---> "sono di quattro tipi, con tre tipologie diverse nella 
prima
linea della risposta"

Original comment by ludovico...@siassb.eu on 26 Feb 2009 at 3:00

[GoogleCodeExporter]

Ciao Ludo, hai ragione ma ti sfugge un dettaglio: una risposta numerica come 
quella
di LLEN o EXISTS ha sempre una caratteristica: non fallisce mai. Dunque non 
devi fare
controllo degli errori in quel caso.

O meglio, se fallisce te lo dice in altro modo, come nel caso di LLEN che 
ritorna -1,
sempre un intero dunque, ma negativo.

Original comment by anti...@gmail.com on 26 Feb 2009 at 3:03

[GoogleCodeExporter]

Sisi ok, il punto è che però devo *sapere* che la risposta è alla richiesta 
EXISTS,
altrimenti non posso essere sicuro che sia su una linea sola.

E' proprio questo il punto, se posso svincolarmi nel client dal matching tra
richiesta e risposta, il codice diventa più semplice e chiaro (e veloce).

Basterebbe, che so, quando sputi fuori la lunghezza del payload come prima riga,
mettere un prefisso L, tipo L3 (3 byte di risposta).

Original comment by ludovico...@siassb.eu on 26 Feb 2009 at 3:08

[GoogleCodeExporter]

Ludo in ogni caso non puoi disaccoppaire mai.

per dire in pseudocode sara' qualcosa come:

func exists
  sendLine "EXISTS ..."
  readIntegerReply

avrai gia' sicuramente qualcosa come: readInlineReply e readBulkReply,
readMultiBulkReply (solo utile per LRANGE). Ti serve una funzione in piu'
da usare in tutte le funzioni che rispondono con un intero.

Credo che il tuo dubbio viene fuori dal fatto che assimili una risposta
numerica ad uno status code +OK -ERR che invece e' un output diverso relativo
ad altri comandi.

Original comment by anti...@gmail.com on 26 Feb 2009 at 3:28

[GoogleCodeExporter]

Ok, continua a sembrarmi inutile nel client dover sapere quale richiesta ha 
generato
una risposta, e più semplice invece avere delle tipologie di risposte di cui
identifichi capo e coda senza sapere niente altro. Ma sei tu il capo e mi 
adeguo. :)

Original comment by ludovico...@siassb.eu on 26 Feb 2009 at 4:03

[GoogleCodeExporter]

Aggiungo che HTTP ad esempio ti permette sempre di sapere quando finisce una
risposta, indipendentemente dalla richiesta (HEAD/GET/POST ecc) che l'ha 
generata.
Idem per il protocollo interno usato da Sphinx (full text search), che fa il
pipelining esatamente come fa Redis. Tanto per citare due esempi che conosco
discretamente.

Original comment by ludovico...@siassb.eu on 26 Feb 2009 at 4:05

[GoogleCodeExporter]

Ciao Ludo, e' senza dubbio una possibilita' quella che tu proponi, e' una 
questione
di scelta. Ad esempio banalmente il server avrebbe potuto rispondere sempre con 
delle
bulk wirte: len e data block. Cio' avrebbe reso necessario da parte del server 
un
maggiore overhead e da parte del client due read invece di una. Pensa che in 
alcune
instanze di memcached con molte richieste si sono accorti che il 60% della CPU 
veniva
utilizzata a fare il parsing o la creazione del protocollo, dunque ho preferito 
la
via meno elegante di risposte ad hoc ma senza alcun overhead. L'altra scelta era
sicuramente anch'essa sensata e piu' elegante ma volevo stare sul minimale in
relazione alla larghezza di banda. L'unica cosa su cui ho sacrificato sono 
stati gli
\r\n perche' non poter usare il server via telnet mi sembrava un prezzo troppo 
alto
da pagare :) Comunque grazie mille della osservazione che in parte condivido.

Original comment by anti...@gmail.com on 26 Feb 2009 at 4:09

[GoogleCodeExporter]

:)

Original comment by ludovico...@siassb.eu on 26 Feb 2009 at 4:10

[GoogleCodeExporter]

Original comment by anti...@gmail.com on 26 Feb 2009 at 4:23

• Changed state: Done