Un client / server TCP è una buona soluzione per un sistema che può essere controllato da una GUI in esecuzione su più piattaforme?

Question

Un client / server TCP è una buona soluzione per un sistema che può essere controllato da una GUI in esecuzione su più piattaforme?

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Considera un software che gira su un sistema dedicato (fondamentalmente una scatola Linux) e controlla alcuni macchinari. Il sistema ha tutte le interfacce hardware necessarie per l'attività. Il software ha anche una GUI per il controllo di detti macchinari.

Tuttavia, questo sistema dovrebbe in seguito essere in grado di essere utilizzato da dispositivi esterni, quindi altri software, utilizzando la stessa GUI o simili, saranno in esecuzione su vari PC, smartphone, ecc. Il SW centrale conterrà un server TCP attraverso il quale il i dispositivi esterni si connetteranno. Il dispositivo centrale con il suo software deve essere sviluppato per primo e la controllabilità da dispositivi esterni sarà un componente aggiuntivo successivo.

La mia proposta per il software "centrale" sarebbe dividerla in due programmi separati. Uno sarebbe un server senza GUI, che gestirà tutto il controllo e le interfacce hardware, e un software separato soddisferà solo i ruoli della GUI.

Naturalmente, una buona separazione MVC è possibile anche all'interno di un singolo programma, ma il vantaggio principale che vedo per la divisione del programma è che la parte della GUI sarà molto più facilmente trasferibile su altri sistemi. In realtà, nel caso di un PC come dispositivo esterno, lo stesso software può essere riutilizzato al 100%. Per altri sistemi, suppongo che sarebbe molto più facile portare un programma da 1 a 1, piuttosto che portare solo la parte GUI di un programma più complesso.

Lo svantaggio principale di questa soluzione è che il sistema iniziale sarà più complicato, poiché la GUI deve comunicare via TCP con la parte di controllo, invece che direttamente all'interno dello stesso programma.

Ci sono altri principali vantaggi e svantaggi nel dividere l'applicazione in due programmi separati che comunicano su TCP?

Lo scopo del progetto è fino a 2 anni per un piccolo team di 2-3 persone.

design mvc tcp

posta vsz 26.01.2016 - 09:19

fonte

3 risposte

Leggi altre domande sui tag design mvc tcp

Gestione delle eccezioni per gli attributi di classe in setter e costruttori [chiuso] Un'interfaccia che include diversi metodi che restituiscono istanze di Object ha senso?

score 3 · Answer 1

Sì, questa separazione dei livelli è sempre una buona cosa, anche se non verrà scritta per un sistema distribuito. Molti sistemi funzionano rendendo i componenti UI o DB il più possibile isolati per consentire una manutenzione o una sostituzione più semplice in futuro.

Altro sistema scrive il programma principale come un'app della riga di comando e poi scrive una GUI per guidarla. Ciò gli consente di essere scriptato e utilizzato anche in un ambiente di interfaccia utente. Non è eccessivamente complicato farlo, basta scrivere il tuo programma e poi scrivere un programma UI più tardi.

Per le tue esigenze, ti consiglio un server web HTTP incorporato. Ce ne sono molti e sono molto leggeri. Non perdi nulla usando uno invece di un server TCP personalizzato (dato che devi ancora implementare la sicurezza, ecc.) Ma ottieni tutte le funzionalità standard del protocollo. Hai anche la possibilità di scrivere il tuo client nel server come un sito Web HTML e controllarlo tramite un browser web.

score 1 · Answer 2

La tua domanda potrebbe essere troppo ampia ed è abbastanza astratta (non sono forniti abbastanza dettagli di implementazione: quale sistema operativo? quale hardware: un processore embedded come Arduino non è la stessa di una motherboard ARM che esegue una variante in tempo reale di Linux; quali macchine? : una macchina da cucire non è la stessa di una centrale nucleare). Inoltre, che tipo di utenti? Sono tutti interni a una società o possono essere "pubblico generico"?

Tuttavia, hai considerato di rendere il tuo software un server web specializzato, utilizzando una libreria di server HTTP come libonion o forse Wt ? (Ovviamente l'HTTP è sopra il TCP); quindi dividerei il software in due parti: una che fornisce il servizio HTTP, l'altra essendo un codice (ad es. Javascript, AJAX, ...) in esecuzione nei browser.

Quindi la tua parte della GUI sarebbe in gran parte sostituita dai browser (su vari dispositivi: desktop, smartphone, ecc ...) che parlano di HTTP (o HTTPS).

Naturalmente, se progettate la vostra applicazione come server web specializzato, dovreste prendere in considerazione molto presto tutte le implicazioni (in particolare sicurezza, attacchi DDOS, ...) e dovreste essere consapevoli delle tecnologie web. Certo, le cose potrebbero essere diverse se tutti gli utenti si trovano all'interno di una piccola intranet aziendale (quindi, probabilmente ti interessa un po 'meno di DDOS)

Ma sul lato client, la maggior parte dei dispositivi per l'utente finale (desktop o laptop con Windows, Linux, MacOSX, tablet, smartphone) - quelli con un display almeno - hanno già sofisticati browser HTML5, su cui si può fare leva. / p>

Potresti prendere in considerazione altri approcci, ad es. chiamate di procedura remota usando JSONRPC, usando FastCGI per interfacciare con alcuni server esterni , ecc ....

Se dividi il tuo software in più parti, devi definire in che modo comunicano e si sincronizzano, e questo è probabilmente il sistema operativo e l'implementazione specifici (ma hai bisogno di alcuni comunicazione inter-processo probabilmente fornita da alcuni sistema operativo , ma potresti avere un approccio unikernel ). Senza dire altro sul tuo software e amp; sistema e amp; macchinari (vale a dire scopo fisico), non otterrete un aiuto veramente significativo.

score 1 · Answer 3

Alcune trappole di cui devi essere a conoscenza:

Autenticazione. A meno che non si desideri che chiunque nel mondo utilizzi la macchina, è necessario assicurarsi che solo le persone autorizzate si colleghino al controller hardware. Un buon modo per farlo potrebbe essere l'utilizzo di TLS con certificato client e server. Come bonus, questo ti offre anche la crittografia per proteggerti da intercettatori e aggressori man-in-the-middle.
Il client non può essere considerato affidabile. Non è possibile presumere che l'utente (autorizzato o non autorizzato) utilizzerà il proprio software client non modificato. Quindi assicurati che l'implementazione del protocollo sul server non permetta nulla che l'interfaccia utente non dovrebbe consentire. Tutti gli input dei client devono essere controllati in modo corretto.
TCP / IP non è molto capace in tempo reale. I pacchetti possono essere improvvisamente ritardati per un sacco di motivi. UDP / IP ha funzionalità in tempo reale leggermente migliori, ma ha un sacco di sorprese anche più spiacevoli, come i pacchetti che arrivano nell'ordine sbagliato o non lo fanno affatto. Quando è importante per il tuo caso d'uso che la macchina esegua i comandi con il tempo esatto, non puoi presumere che i comandi arrivino al server con le stesse differenze temporali tra loro quando lasciano il client. Ad esempio: se si desidera che la macchina venga eseguita esattamente per 5,637 secondi, l'invio del messaggio on-on e 5,637 secondi dopo l'invio del messaggio non funzionante potrebbe non funzionare poiché entrambi i messaggi avranno bisogno di un orario diverso per arrivare al server. Dovresti inviare un comando "Attiva, attendi 5.637 secondi, disattiva, ora esegui" in un messaggio.