JAVA/TomCat: trasformarlo in un server non http

[cicciopasticcio1]

Salve a tutti, ho bisogno di programmare un server e vorrei che esso interagisca col client interamente via XML, senza quindi passare dal protocollo HTTP.

Avevo pensato perciò a tomcat, ho fatto la servlet e l'ho posizionata su localhost, in modo tale che sia accessibile dalla radice.

Però mi sto accorgendo che non riesco a gestire le richieste e le risposte prescidendo dall'http, visto che a quanto pare anche la classe GenericServlet, che mi sembrava l'ideale per questo lavoro, lo utilizza.

Qualcuno sa per caso cosa fare a questo punto? Vorrei un tipo di comunicazione di questo tipo:

// richiedi l'autenticazione ed un session id
<query type="100" user="utente1" password="secret" />
// risponde dicendo che l'utente è autorizzato e gli da un session id
<response type="101">3223hbbv342uy1jjj1</response>
// richiedi dei dati generici
<query type="###" />

e via dicendo..

Mi consigliate qualcosa?

[idoido]

sinceramente ti consiglio di capire meglio cosa ti serve

http è un protocollo che trasporta dei dati, il contenuto lo decidi tu, a che pro modificare il modo in cui i dati vengono trasportati?

[cicciopasticcio1]

Originariamente inviato da idoido

sinceramente ti consiglio di capire meglio cosa ti serve

http è un protocollo che trasporta dei dati, il contenuto lo decidi tu, a che pro modificare il modo in cui i dati vengono trasportati?

Potrei farlo anche con HTTP, però sarebbe meglio un protocollo ad hoc. Le comuncazioni che dovrei fare sono caratterizzate da avere una quantità di dati inviati molto vicina alla quantità di dati ricevuti.

HTTP non è fatto per questo: certo potrei addattarmi e passare tutto via post, ma credo che troverei meno problemi nel sostituire HTTP con un un protocollo ad hoc, anche in termini di pesantezza: essendo un'applicazione per smartphone sarebbe più leggero nel modo in cui l'ho pensata.

Ovvio che se poi trovo troppi problemi faccio un passo indietro e poi torno sull'HTTP.

Ah, ho trovato anche questo che fa al caso mio, un framwork per java
http://mina.apache.org/mina-project/...art-guide.html
Apache Mina

sembrerebbe ottimo, ma se si può fare efficacemente anche con tomcat tanto meglio.

[idoido]

scusami, ma qui secondo me stiamo continuando a parlare del nulla.

l'overhead (e quindi la pesantezza) del protocollo http ti sembra troppa? stiamo parlando di bytes, poniamo che invii in http un file xml da 1MB, non sono certo gli header dello scambio http che ti rallentano il tutto.

poi parli di applicazioni per smartphone, puoi sempre utilizzare le socket (e quindi fai passare i dati come vuoi), poi quando avrai i primi problemi con firewall & co. capirai perché si usa http per scambiare dati tra un client e un server.

[cicciopasticcio1]

I pacchetti da scambiare sono piccoli e frequenti, quindi l'overhead peserebbe abbastastanza nella conversazione.
Inoltre un protocollo ad hoc mi sembrava molto elegante come soluzione ed in più minimizzerebbe la grandezza dei pacchetti.

Per il client utilizzerei ovviamente le socket, per il server invece non volevo scendere troppo di livello e quindi usare le socket perchè la questione multi threading avrebbe complicato le cose e reso il programma troppo instabile (visto che non sono poi così esperto, è la prima volta che uso java). Per questo ho pensato a tomcat, visto che ho letto che può gestire servlet non html, anche se non ho ancora trovato un esempio decente.

Fatto stà che se la questione si fa più complessa del previsto dovrei necessariamente lasciar perdere e tornare sull'http.

Pensi proprio che sia una pessima idea?

[idoido]

Originariamente inviato da cicciopasticcio1

I pacchetti da scambiare sono piccoli e frequenti, quindi l'overhead peserebbe abbastastanza nella conversazione.
Inoltre un protocollo ad hoc mi sembrava molto elegante come soluzione ed in più minimizzerebbe la grandezza dei pacchetti.

Per il client utilizzerei ovviamente le socket, per il server invece non volevo scendere troppo di livello e quindi usare le socket perchè la questione multi threading avrebbe complicato le cose e reso il programma troppo instabile (visto che non sono poi così esperto, è la prima volta che uso java). Per questo ho pensato a tomcat, visto che ho letto che può gestire servlet non html, anche se non ho ancora trovato un esempio decente.

Fatto stà che se la questione si fa più complessa del previsto dovrei necessariamente lasciar perdere e tornare sull'http.

Pensi proprio che sia una pessima idea?

secondo me, almeno in questa fase di sviluppo dell'applicazione, è inutile.
concentrati nel far funzionare l'applicazione, e poi vedi i colli di bottiglia e le possibili ottimizzazioni, creare un protocollo o modificare un server (web o di altro tipo) mi sembra una esagerazione se non c'è una precisa motivazione dietro (e l'invio di pacchetti piccoli e frequenti non lo è)

ps: prova a guardare il protocollo XMPP, magari fa al caso tuo.

[cicciopasticcio1]

Capisco,
ma per il problema firewall non si potrebbe comunque parlare sulla porta 80 ma col protocollo che dico io? Non penso che il firewall se ne accorga !