Web Service o puro TCP

Question

Web Service o puro TCP

#1 da (0 voti)

2

Stiamo provando a stabilire una rete 6LoWPAN .

I nostri dispositivi hanno solo la connessione 6LoWPAN, quindi abbiamo bisogno di un bridge per collegarli al server CMS. Un piccolo computer (qualcosa come BeagleBone) che esegue Linux funge da bridge e comunica con più dispositivi tramite 6LoWPAN e fornisce la connessione TCP al server.

In questo bridge abbiamo alcune applicazioni che forniscono API per il controllo e il recupero dei dati dai nostri dispositivi. Per ora è un po 'una rete fittizia. Bridge riceve richieste da TCP e le trasferisce ai dispositivi.

A proposito, i dispositivi non solo rispondono alle richieste ma anche inviano notifiche ogni volta che si verifica una situazione di allarme.

Ora vogliamo rendere il bridge più intelligente. Stiamo pensando di sviluppare un servizio web sul bridge e fornire alcune funzionalità (come configurazione, controllo programmato, gestione di gruppo, ecc.).

Non sarà un problema fornire un servizio web basato sul SOAP sul bridge. Ma non siamo sicuri se dovremmo sviluppare un servizio web per la nostra rete.

L'apertura di una connessione TCP dal server a tutti i ponti è un approccio migliore o la comunicazione ai bridge tramite il servizio web è un approccio migliore?

web-services tcp

posta Emre Erişgen 02.10.2015 - 15:25

fonte

1 risposta

Leggi altre domande sui tag web-services tcp

Risoluzione dei conflitti per sincronizzazione offline bidirezionale CQRS comando "privato"

score 0 · Accepted Answer

Per il tuo caso d'uso particolare, penserei che la comunicazione HTTP sarebbe una soluzione migliore di TCP.

In generale, il motivo principale per cui scegliere TCP su HTTP sarebbe quando le prestazioni erano di primaria importanza e si poteva mantenere una connessione attiva. Puoi anche inviare dati in entrambe le direzioni. Con TCP, hai più o meno il pieno controllo di ciò che viene inviato via cavo. (Ma se usi qualcosa di stravagante, devi essere sicuro di poter inserire il tuo codice personalizzato dall'altra parte per leggerlo.)

Tuttavia, potrebbe essere troppo aspettarsi che il bridge mantenga una connessione TCP. (Stiamo parlando di collegamenti wifi al bridge?) Mentre HTTP è richiesta / risposta, quindi deve solo essere stabile abbastanza a lungo da inviare e ricevere. (I messaggi idempotenti sono una buona idea a prescindere.) HTTP scalerà meglio delle connessioni TCP attive se ci sono molti controller. L'HTTP ha ubiquità: ci sono molti server HTTP disponibili e praticamente qualsiasi linguaggio e piattaforma possono inviare una richiesta HTTP con poco sforzo. HTTP è potenzialmente più facile da eseguire il debug poiché puoi esaminare il formato del filo (testo) con occhi umani.

Con WebSocket si possono avere molti degli stessi vantaggi e svantaggi di TCP, a condizione che i dispositivi possano utilizzarlo. Un vantaggio di WebSocket su TCP è che la maggior parte dei firewall non blocca la porta HTTP utilizzata da WebSockets, mentre la porta TCP personalizzata scelta potrebbe essere bloccata.