Approccio progettuale all'outsourcing di un socket in una propria discussione

3

Desidero estendere un server esistente scritto in C ++ per poter comunicare con un altro server tramite websocket ( ad esempio per la registrazione o l'autorizzazione dell'utente). Tutti gli esempi (inclusa la molto ben scritta Guida di Beej ) che ho trovato hanno un infinito loop (es. per, o while) per gestire i metodi di invio e ricezione del socket. Il problema principale di questi esempi (ad es. Server / client di chat) è che i server sono focalizzati sui socket, il che significa che un server si blocca durante il processo di invio e ricezione e non è disponibile per altre operazioni.

Bene, quindi ho pensato che potrei esternalizzare l'intera comunicazione socket in una propria discussione e chiamare solo il metodo send dal programma principale, mentre l'intero processo di invio della richiesta e attendere la risposta è fatto all'interno del thread. Quando arriva una risposta dall'altro server, i thread inviano le informazioni al programma principale, che convalida ed elabora le informazioni. A causa della mia esperienza con node.js mi piacerebbe avere una specie di callback per elaborare la risposta nel programma principale (non sarebbe facile?).

Oltre alla mia perdita di conoscenza su come posso scambiare dati tra il processo genitore e i thread (che era già stato avviato) sto faticando a trovare un esempio, come evitare un socket per bloccare l'intero programma, mentre il genitore il programma può concentrarsi su altre attività e può utilizzare il socket in modo "asincrono". Sono sicuro che questo non è un problema insolito e sarei felice se qualcuno ha un suggerimento o un'idea.

La mia idea è di usare fork () per creare un figlio che gestisca tutti gli I / O con i socket (quindi non mi interessa se blocchi) e usare un pipe per asincronizzare leggere e scrivere tra genitore e figlio. Ma sto ancora cercando un esempio utile.

    
posta FredFloete 09.07.2015 - 17:45
fonte

1 risposta

1

La lettura del blocco è antiquata; i server moderni utilizzano una lettura asincrona in cui il programma passa un buffer all'API in cui i dati dovrebbero finire e ottenere un token che rappresenta l'operazione. Nessun thread aggiuntivo necessario.

Diversi token possono essere aspettati allo stesso tempo in modo che il server possa inviare diverse letture e scritture e quindi attendere tutti i token fino a quando non è terminato e quando si usa il token che ha risvegliato il thread per identificare quale operazione ha avuto successo e continua il lavoro necessario per quella presa. (questo è ciò che node.js fa dietro le quinte).

Sebbene il problema con il thread che comunica sia un problema produttore / consumatore , il thread principale scrivere su ogni socket è un produttore e ogni thread writing è un consumatore. Ogni thread che legge dal socket è un produttore e il thread principale in attesa delle letture è un consumatore.

    
risposta data 09.07.2015 - 17:58
fonte

Leggi altre domande sui tag