[Risolto] Non usare quella porta
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
[Risolto] Non usare quella porta
Ciao a tutti.
A seguito di uno scambio in questa sezione qualche tempo fa, sono rimasto con alcuni dubbi.
Ho scritto un programma in cui due computer con due diversi indirizzi ip nella stessa LAN (sono collegati allo stesso modem) comunicano tra loro con protocollo tcp/ip e usando una specifica porta.
Non mi metto a postare il programma perché non avrebbe molto senso ai fini della discussione, dico solo che uso una libreria che si chiama 0MQ e i relativi binding per C++ (sul server) e Python (sul client) (o viceversa).
Insomma, fino allo scambio di qualche tempo fa, io facevo partire serenamente i due programmi, prima lato server e poi lato client, e tutto funzionava a meraviglia.
Ora invece mi chiedo: quali sono le precauzioni che si devono prendere quando si comunica tra due pc in questo modo?
Per precauzioni intendo quelle atte a evitare che si usi una porta già in uso da altri programmi, o che si usi una porta che successivamente possa magari essere presa da altri programmi per comunicare.
La mia preoccupazione è che di botto la mia applicazione possa smettere di funzionare perché al client e al server iniziano ad arrivare "messaggi estranei" che mandino in confusione il programma.
Al momento mando dal client al server solo una lista di stringhe o delle singole stringhe formattate in csv, mentre il server fa le sue elaborazioni e manda delle stringhe un po' più complesse ma sempre testuali e che indicano delle operazioni che il client deve eseguire.
Aspetto con ansia vostre delucidazioni
A seguito di uno scambio in questa sezione qualche tempo fa, sono rimasto con alcuni dubbi.
Ho scritto un programma in cui due computer con due diversi indirizzi ip nella stessa LAN (sono collegati allo stesso modem) comunicano tra loro con protocollo tcp/ip e usando una specifica porta.
Non mi metto a postare il programma perché non avrebbe molto senso ai fini della discussione, dico solo che uso una libreria che si chiama 0MQ e i relativi binding per C++ (sul server) e Python (sul client) (o viceversa).
Insomma, fino allo scambio di qualche tempo fa, io facevo partire serenamente i due programmi, prima lato server e poi lato client, e tutto funzionava a meraviglia.
Ora invece mi chiedo: quali sono le precauzioni che si devono prendere quando si comunica tra due pc in questo modo?
Per precauzioni intendo quelle atte a evitare che si usi una porta già in uso da altri programmi, o che si usi una porta che successivamente possa magari essere presa da altri programmi per comunicare.
La mia preoccupazione è che di botto la mia applicazione possa smettere di funzionare perché al client e al server iniziano ad arrivare "messaggi estranei" che mandino in confusione il programma.
Al momento mando dal client al server solo una lista di stringhe o delle singole stringhe formattate in csv, mentre il server fa le sue elaborazioni e manda delle stringhe un po' più complesse ma sempre testuali e che indicano delle operazioni che il client deve eseguire.
Aspetto con ansia vostre delucidazioni
Ultima modifica di vaeVictis il lunedì 6 dicembre 2021, 17:36, modificato 1 volta in totale.
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
Re: Non usare quella porta
Forse sono ingenuo ma...
Se impostassi una regola sul firewall (lato client o lato server o entrambi) non dovrebbe prevenire l'uso "improprio" di quella porta da parte di altre applicazioni?
O, in alternativa, il server non potrebbe emettere un token specifico utilizzabile solo dal client? (E, a sua volta, far passare solo i messaggi da token autorizzati?)
Se impostassi una regola sul firewall (lato client o lato server o entrambi) non dovrebbe prevenire l'uso "improprio" di quella porta da parte di altre applicazioni?
O, in alternativa, il server non potrebbe emettere un token specifico utilizzabile solo dal client? (E, a sua volta, far passare solo i messaggi da token autorizzati?)
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
Re: Non usare quella porta
Non ci avevo proprio pensato e così su due piedi non saprei che pensare. Potrebbe funzionare, ma in questo caso dovrei comunque scegliere una porta che non viene usata da altri servizi, no? Come mi regolo?
Temo che questo non sia fattibile. Ci rifletto un po' e ti faccio sapere.O, in alternativa, il server non potrebbe emettere un token specifico utilizzabile solo dal client? (E, a sua volta, far passare solo i messaggi da token autorizzati?)
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
Re: Non usare quella porta
Una cosa del genere funziona con il gestionale degli asset che usiamo in azienda (che oltretutto è open source).
Per usare le API RESTful e fare query in batch e reperire tabulati custom (senza passare dall'interfaccia grafica) puoi farlo solo previa esibizione del token rilasciato per utente.
Per quanto riguarda l'abuso di porte: per motivi troppo lunghi da spiegare io uso ssh sulla porta 443 e funziona perfettamente al momento. Chissà cosa succederebbe se installassi Apache...
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
Re: Non usare quella porta
Non ho capito se quello che mi stai suggerendo consiste nell'aggiungere una sequenza di controllo alle stringhe che invio dal client al server, e un'altra sequenza di controllo per le stringhe che invio dal server al client.
E poi fare un controllo da ambo i lati e accettare solo quelle con il giusto carattere di controllo e rifiutare le altre.
È questo? Fammi sapere.
Se è questo, ho provato a implementarlo ma c'è un errore nel fatto che uso il contesto REQ/REP e temo non vada bene.
Non va bene perché, in questo contesto, le due parti fanno un balletto di invio e ricevo da un lato, e ricevo e invio dall'altro.
Se si interrompe perché una o entrambe le parti ricevono un messaggio errato e devono rimettersi in modalità di ricevimento dopo averlo ignorato il balletto sbarella e il programma crasha.
Mi sa che mi devo rileggere la documentazione di ZMQ.
E poi fare un controllo da ambo i lati e accettare solo quelle con il giusto carattere di controllo e rifiutare le altre.
È questo? Fammi sapere.
Se è questo, ho provato a implementarlo ma c'è un errore nel fatto che uso il contesto REQ/REP e temo non vada bene.
Non va bene perché, in questo contesto, le due parti fanno un balletto di invio e ricevo da un lato, e ricevo e invio dall'altro.
Se si interrompe perché una o entrambe le parti ricevono un messaggio errato e devono rimettersi in modalità di ricevimento dopo averlo ignorato il balletto sbarella e il programma crasha.
Mi sa che mi devo rileggere la documentazione di ZMQ.
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
- nuzzopippo
- Entusiasta Emergente
- Messaggi: 1623
- Iscrizione: giovedì 12 ottobre 2006, 11:34
Re: Non usare quella porta
Credo che sia meglio leggere riguardo il funzionamento del TCP-IP e delle reti in generale, è un discorso di cui abbiamo già parlato in questo post, @vae.
Certo, fai benissimo a cercare opinioni e chiarirTi le idee ma che mi risulti una specifica porta di rete non può essere utilizzata contemporaneamente da due processi diversi, perciò potrai avere uno, ed uno soltanto, server in ascolto su detta porta, è il sistema operativo stesso ad impedirlo.
Quindi, o la trovi libera ed il tuo server si mette in ascolto occupandola ed impedendo a qualsiasi altro processo di utilizzarla, oppure non riesce a stabilire una connessione ed entra in errore.
Dal lato client, la cosa è insignificante, dato che di norma ci si connette casualmente ad una delle porte date libere dal sistema operativo.
Questo è quanto ci ho capito io negli anni ma non sono poi ferratissimo in materia (e sono "vecchio" anche come concetti), comunque è una domanda più da porre nella sezione "reti", vi sono certo utenti più esperti di me che potranno dare risposte più attendibili a domande tipo "è possibile far agire due processi di ascolto diversi sullo stesso indirizzo IP e porta?", io ritengo di no ma, come detto, non sono abbastanza ferrato in merito.
Fatti non foste a viver come bruti ...
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
Re: Non usare quella porta
Sì, infatti la domanda specifica che ho fatto era per ampliare il discorso che abbiamo fatto in quell'altra discussionenuzzopippo ha scritto: ↑martedì 30 novembre 2021, 10:58Credo che sia meglio leggere riguardo il funzionamento del TCP-IP e delle reti in generale, è un discorso di cui abbiamo già parlato in questo post, @vae.
Certo, fai benissimo a cercare opinioni e chiarirTi le idee ma che mi risulti una specifica porta di rete non può essere utilizzata contemporaneamente da due processi diversi, perciò potrai avere uno, ed uno soltanto, server in ascolto su detta porta, è il sistema operativo stesso ad impedirlo.
Quindi, o la trovi libera ed il tuo server si mette in ascolto occupandola ed impedendo a qualsiasi altro processo di utilizzarla, oppure non riesce a stabilire una connessione ed entra in errore.
Dal lato client, la cosa è insignificante, dato che di norma ci si connette casualmente ad una delle porte date libere dal sistema operativo.
Questo è quanto ci ho capito io negli anni ma non sono poi ferratissimo in materia (e sono "vecchio" anche come concetti), comunque è una domanda più da porre nella sezione "reti", vi sono certo utenti più esperti di me che potranno dare risposte più attendibili a domande tipo "è possibile far agire due processi di ascolto diversi sullo stesso indirizzo IP e porta?", io ritengo di no ma, come detto, non sono abbastanza ferrato in merito.
Tengo in considerazione il suggerimento di aprire una discussione in reti, non ci avevo pensato.
Grazie.
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
Re: Non usare quella porta
So bene che portare una esperienza personale, lascia sempre un po' il tempo che trova. Ma, non essendomi mai interfacciato direttamente con una problematica del genere, è il massimo che possa proporti. Se poi mi confermi che ci sono problemi di implementazione, amen, io ci ho provato. Se mi viene in mente qualche altra idea ti terrò aggiornato.vaeVictis ha scritto: ↑martedì 30 novembre 2021, 0:00Non ho capito se quello che mi stai suggerendo consiste nell'aggiungere una sequenza di controllo alle stringhe che invio dal client al server, e un'altra sequenza di controllo per le stringhe che invio dal server al client.
E poi fare un controllo da ambo i lati e accettare solo quelle con il giusto carattere di controllo e rifiutare le altre.
È questo? Fammi sapere.
Se è questo, ho provato a implementarlo ma c'è un errore nel fatto che uso il contesto REQ/REP e temo non vada bene.
Non va bene perché, in questo contesto, le due parti fanno un balletto di invio e ricevo da un lato, e ricevo e invio dall'altro.
Se si interrompe perché una o entrambe le parti ricevono un messaggio errato e devono rimettersi in modalità di ricevimento dopo averlo ignorato il balletto sbarella e il programma crasha.
Mi sa che mi devo rileggere la documentazione di ZMQ.
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
- nuzzopippo
- Entusiasta Emergente
- Messaggi: 1623
- Iscrizione: giovedì 12 ottobre 2006, 11:34
Re: Non usare quella porta
Fai bene ad ampliare ... per altro mi son letto con calma l'intero post e mi son sorte un paio di perplessità, da quanto ho compreso il problema che Ti poni è il corretto riconoscimento tra server e client ma non c'è un login di mezzo?, oppure la comunicazione è indiscriminata?
Quand'anche la comunicazione sia senza riconoscimento dell'user (indiscriminata quindi) è possibile far emettere al server un messaggio di benvenuto? Se si, io ho utilizzato tale messaggio per determinare un protocollo di riconoscimento dei miei server postgresql, ftp, ed altro, al passaggio della rete aziendale da indizzi IP fissi gestiti all'interno ad indirizzi forniti da DHCP gestiti dall'esterno, implementando dei processi di scansione della rete che individuassero le macchine "giuste", è un mezzo semplice e che ha funzionato bene nel mio caso (certo ho dovuto sfanculare un po' di geni che ci avevano messo ko la comunicazione interna)
Fatti non foste a viver come bruti ...
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
Re: Non usare quella porta
@nuzzopippo
Il problema è che mi sto scrivendo il codice da solo. Inizialmente facevo tutto senza pormi troppi problemi, ma ora vorrei riscrivere i codici in modo corretto.
Entro nel dettaglio.
In primo luogo, sto usando zmq perché è molto performante e semplice, oltre che facilmente scalabile e via dicendo.
Inoltre, c'è il problema che il client deve per forza girare su windows, mentre il server grazie al cielo lo faccio girare su Linux.
Correggimi se sbaglio, ma a quanto ho letto, lasciando stare zmq e gestendo direttamente la comunicazione tra socket, questi ultimi si comportano differentemente tra linux e windows e vorrei evitare di mettermi a studiare le caratteristiche di windows.
Ciò detto, faccio riferimento a questo semplice codice per il server
e a questo per il client
In pratica il client manda stringhe
il server le riceve e risponde con la stessa stringa più la string " | World"
il client a sua volta riceve la stringa e la stampa per vedere se tutto ha funzionato.
Ho fatto una semplice prova e in effetti lanciare due server con la stessa porta ha come conseguenza che il secondo crashi al momento della connessione.
Il problema è però nei client.
Se ne lancio due, con due --clientName diversi, effettivamente al server arrivano messaggi da entrambi i client e questo risponde sia al primo che al secondo, in un ordine che dipende dall'ordine di arrivo dei messaggi inviati dal client.
Il problema è che in questo contesto, ossia in REQ/REP le due operazioni sono in un certo senso sincronizzate, nel senso che sia su client sia su server a una REQ deve corrispondere una REP.
L'idea di fare una verifica su una stringa di controllo aggiunta al messaggio inviato al server, in effetti, non è male, ma bisogna implementare un altro contesto, che non abbia la rogna di questa corrispondenza REQ/REP.
Il resto del discorso che fai, sulle autenticazioni e sul messaggio di benvenuto, non riesco a comprenderlo per mia ignoranza.
Il problema è che mi sto scrivendo il codice da solo. Inizialmente facevo tutto senza pormi troppi problemi, ma ora vorrei riscrivere i codici in modo corretto.
Entro nel dettaglio.
In primo luogo, sto usando zmq perché è molto performante e semplice, oltre che facilmente scalabile e via dicendo.
Inoltre, c'è il problema che il client deve per forza girare su windows, mentre il server grazie al cielo lo faccio girare su Linux.
Correggimi se sbaglio, ma a quanto ho letto, lasciando stare zmq e gestendo direttamente la comunicazione tra socket, questi ultimi si comportano differentemente tra linux e windows e vorrei evitare di mettermi a studiare le caratteristiche di windows.
Ciò detto, faccio riferimento a questo semplice codice per il server
Codice: Seleziona tutto
#! /usr/bin/env python3
#-*- coding: utf-8 -*-
#
# Hello World server in Python
# Binds REP socket to tcp://*:5555
# Expects b"Hello" from client, replies with b"World"
#
import time
import zmq
context = zmq.Context()
socket = context.socket(zmq.REP)
socket.bind("tcp://*:5555")
while True:
# Wait for next request from client
message = socket.recv()
print(f"Received request: {message}")
# Do some 'work'
time.sleep(1)
# Send reply back to client
socket.send_string(message.decode("utf-8") + " | World")
Codice: Seleziona tutto
#! /usr/bin/env python3
#-*- coding: utf-8 -*-
#
# Hello World client in Python
# Connects REQ socket to tcp://localhost:5555
#
import argparse
import zmq
parser = argparse.ArgumentParser()
parser.add_argument("--clientName", type = str, required = True)
parser.add_argument("--range", type = int, required = True)
args = parser.parse_args()
context = zmq.Context()
# Socket to talk to server
print("Connecting to hello world server...")
socket = context.socket(zmq.REQ)
socket.connect("tcp://localhost:5555")
# Do 10 requests, waiting each time for a response
for request in range(args.range):
print(f"Sending request {request} ...")
socket.send_string("Hello number {} from {}".format(request, args.clientName))
# Get the reply.
message = socket.recv()
print(f"Received reply {request} [ {message} ]")
Codice: Seleziona tutto
Hello number N from NOME_CLIENT
Codice: Seleziona tutto
Hello number N from NOME_CLIENT | World
Ho fatto una semplice prova e in effetti lanciare due server con la stessa porta ha come conseguenza che il secondo crashi al momento della connessione.
Il problema è però nei client.
Se ne lancio due, con due --clientName diversi, effettivamente al server arrivano messaggi da entrambi i client e questo risponde sia al primo che al secondo, in un ordine che dipende dall'ordine di arrivo dei messaggi inviati dal client.
Il problema è che in questo contesto, ossia in REQ/REP le due operazioni sono in un certo senso sincronizzate, nel senso che sia su client sia su server a una REQ deve corrispondere una REP.
L'idea di fare una verifica su una stringa di controllo aggiunta al messaggio inviato al server, in effetti, non è male, ma bisogna implementare un altro contesto, che non abbia la rogna di questa corrispondenza REQ/REP.
Il resto del discorso che fai, sulle autenticazioni e sul messaggio di benvenuto, non riesco a comprenderlo per mia ignoranza.
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
- Claudio_F
- Entusiasta Emergente
- Messaggi: 1463
- Iscrizione: lunedì 28 maggio 2012, 18:49
- Desktop: Mate/Gnome
- Distribuzione: Ubu22.04
Re: Non usare quella porta
Un client è già distinguibile da IP e porta mittente. Basta che il server tenga un dizionario di client attivi, e per ciascuno di essi istanzi un oggetto che gestirà "il balletto" (da/verso lo specifico client) tramite una macchina a stati.L'idea di fare una verifica su una stringa di controllo aggiunta al messaggio inviato al server, in effetti, non è male, ma bisogna implementare un altro contesto, che non abbia la rogna di questa corrispondenza REQ/REP.
- nuzzopippo
- Entusiasta Emergente
- Messaggi: 1623
- Iscrizione: giovedì 12 ottobre 2006, 11:34
Re: Non usare quella porta
Capisco, TCP-IP e socket sono ossi duri, da rimetterci i denti, come sai da altre occasioni al momento ho sempre trattato direttamente coi socket, ho voluto fare una prova installando pyzmq in un venv e manipolato il tuo codice per "creare" una sorta di verifica della identità di un "server" (non so se sia definibile così) con connessione contestuale da due indirizzi diversi
Il codice manipolato del server:
Codice: Seleziona tutto
#! /usr/bin/env python3
#-*- coding: utf-8 -*-
#
# Hello World server in Python
# Binds REP socket to tcp://*:5555
# Expects b"Hello" from client, replies with b"World"
#
import time
import zmq
context = zmq.Context()
socket = context.socket(zmq.REP)
socket.bind("tcp://*:5555")
identity = 'ZMQ Echo Server SRN 001'
while True:
# Wait for next request from client
data = socket.recv()
message = data.decode('utf-8')
print("received :", message)
if message == 'identify':
print('Send identity')
socket.send_string(identity)
elif message == 'quit':
socket.send_string('bye')
time.sleep(1)
break
else:
# Send reply back to client
socket.send_string(message + " | World")
# Do some 'work'
time.sleep(1)
print('Closing for request')
socket.close()
Codice: Seleziona tutto
#! /usr/bin/env python3
#-*- coding: utf-8 -*-
#
# Hello World client in Python
# Connects REQ socket to tcp://localhost:5555
#
#import argparse
import zmq
import sys
'''parser = argparse.ArgumentParser()
parser.add_argument("--clientName", type = str, required = True)
parser.add_argument("--range", type = int, required = True)
args = parser.parse_args()'''
def verify_identity(response, identity):
if response != identity:
return False
return True
context = zmq.Context()
# Socket to talk to server
address = sys.argv[1]
svr_identity = sys.argv[2]
conn_str = 'tcp://{}:5555'.format(address)
print('Connecting to hello world server id "' + svr_identity + '"')
socket = context.socket(zmq.REQ)
socket.connect(conn_str)
# Do 10 requests, waiting each time for a response
'''for request in range(args.range):
print(f"Sending request {request} ...")
socket.send_string("Hello number {} from {}".format(request, args.clientName))
# Get the reply.
message = socket.recv()
print(f"Received reply {request} [ {message} ]")'''
socket.send_string('identify')
data = socket.recv()
message = data.decode('utf-8')
print('Receiver :', message)
if verify_identity(message, svr_identity):
print('Server identity Ok')
else:
print('Bad server identify - closing')
socket.close()
exit()
command = ' '
while command:
command = input('Command : ')
if command:
socket.send_string(command)
data = socket.recv()
message = data.decode('utf-8')
print(message)
if command == 'quit':
print('Closing and exit')
socket.close()
exit()
Output del server:
Codice: Seleziona tutto
python zmq_svr.py
received : identify
Send identity
received : identify
Send identity
received : identify
Send identity
received : saluta nuzzo
received : saluta pippo
received : quit
Closing for request
(zmq_v) NzP:~$
Codice: Seleziona tutto
python zmq_cli.py localhost "ZMQ Echo Server SRN 002"
Connecting to hello world server id "ZMQ Echo Server SRN 002"
Receiver : ZMQ Echo Server SRN 001
Bad server identify - closing
(zmq_v) NzP:~$ python zmq_cli.py localhost "ZMQ Echo Server SRN 001"
Connecting to hello world server id "ZMQ Echo Server SRN 001"
Receiver : ZMQ Echo Server SRN 001
Server identity Ok
Command : saluta nuzzo
saluta nuzzo | World
Command : quit
bye
Closing and exit
(zmq_v) NzP:~$
connessione da diverso IP
Codice: Seleziona tutto
... HO SBAGLIATO LA FINESTRA E COPIATO NUOVAMENTE L'OUTPUT PRECEDENTE
Chiedo scusa, non lo ho più disponibile, comunque basta provare il codice con localhost ed indirizzo di rete contemporaneamente
(zmq_v) NzP:~$
Ora, non voglio minimamente dire che sono rose e fiori, son spine ed ortiche, ma se occorre riconoscere il server questo è un mezzo rozzo ma possibile.
Per altro, tutti si sta ad imparare, abbiamo le nostre montagne di conoscenza da scalare
Fatti non foste a viver come bruti ...
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
Re: Non usare quella porta
Ti ringrazio per gli esempi di codice. Al momento mi risultano un po' ostici perché sto constatando sono proprio all'oscuro di questo mondo.
Comunque no, ma che rose e fiori, è un sedere enorme da farsi
Ho appena finito di leggermi i pattern della programmazione a oggetti, ora mi farò questa immersione nei pattern del networking, vediamo se li capisco e riesco ad applicarli.
Appena riesco a comprendere il tuo codice ti aggiorno
Comunque no, ma che rose e fiori, è un sedere enorme da farsi
Ho appena finito di leggermi i pattern della programmazione a oggetti, ora mi farò questa immersione nei pattern del networking, vediamo se li capisco e riesco ad applicarli.
Appena riesco a comprendere il tuo codice ti aggiorno
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
Re: Non usare quella porta
Mi sto leggendo velocemente la documentazione di ZMQ, perché credo che il mio problema possa risolversi senza troppi sbattimenti, con uno dei pattern suggeriti nei capitoli successivi della guida.
Sto notando che chi ha scritto la guida ha un umorismo terribile. La guida è infarcita di battute terrificanti
Evito di metterne perché siamo in sezione tecnica, ma vi consiglio caldamente di buttarci un occhio anche solo per l'umorismo.
Ciò detto, credo di riuscire ad aggiornarvi la prossima settimana, se non la successiva.
Sto notando che chi ha scritto la guida ha un umorismo terribile. La guida è infarcita di battute terrificanti
Evito di metterne perché siamo in sezione tecnica, ma vi consiglio caldamente di buttarci un occhio anche solo per l'umorismo.
Ciò detto, credo di riuscire ad aggiornarvi la prossima settimana, se non la successiva.
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
- nuzzopippo
- Entusiasta Emergente
- Messaggi: 1623
- Iscrizione: giovedì 12 ottobre 2006, 11:34
Re: Non usare quella porta
Ho dato una occhiata alla introduzione nella guida on-line laterale, vedo che ne usa molti, tra cui il pattern "Publisher/Subscriber", l'avevo pensato, poco tempo fa mi son divertito a far funzionare una interfaccia grafica basandola, per il grosso su tale pattern, è stato un giochino piacevole.
Aspetto di vedere le Tue conclusioni con 0MQ
Fatti non foste a viver come bruti ...
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
Re: Non usare quella porta
Il pattern PUB/SUB inoltre prevede dei filtri.
Appena finisco di leggere la documentazione posto un esempio.
Anche se un esempio semplice semplice è presente nella prima e unica risposta a questa discussione di stackoverflow
Appena finisco di leggere la documentazione posto un esempio.
Anche se un esempio semplice semplice è presente nella prima e unica risposta a questa discussione di stackoverflow
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
Re: Non usare quella porta
Ciao @Claudio_F, mi era sfuggito il tuo intervento.Claudio_F ha scritto: ↑martedì 30 novembre 2021, 14:47Un client è già distinguibile da IP e porta mittente. Basta che il server tenga un dizionario di client attivi, e per ciascuno di essi istanzi un oggetto che gestirà "il balletto" (da/verso lo specifico client) tramite una macchina a stati.L'idea di fare una verifica su una stringa di controllo aggiunta al messaggio inviato al server, in effetti, non è male, ma bisogna implementare un altro contesto, che non abbia la rogna di questa corrispondenza REQ/REP.
In ZMQ l'IP del mittente non è reperibile dal messaggio.
C'è modo di reperirlo ma va contro i principi con i quali è costruita la libreria perché si deve andare a mettere mano all'implementazione.
La guida indica proprio di non farlo perché i pattern che si utilizzano consentono di farne a meno.
Non avevo mai approfondito lo studio di questa libreria, è spaziale.
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
- vaeVictis
- Imperturbabile Insigne
- Messaggi: 4703
- Iscrizione: venerdì 27 luglio 2012, 17:58
- Desktop: Gnome
- Distribuzione: Ubuntu 20.04 64bit
Re: Non usare quella porta
Ciao a tutti, la discussione per me è risolta. Non entro molto nel dettaglio, perché dovrei riassumere circa tre capitoli di documentazione.
In pratica, si possono filtrare i messaggi interessati, con il pattern PUB/SUB.
Inoltre il pattern più indicato per il mio problema non è quello che usavo, ma al momento sto adottando il REQ-ROUTER-queue-DEALER-REP.
E' una sorta di pattern multi thread (sta libreria gestisce anche questioni relative al multithread*, l'hanno pensata gli alieni).
In pratica, quando mi arrivano i dati da REQ, con un thread li carico su un db e con gli altri li analizzo per fare i miei conti, quando questi hanno finito mandano indietro le loro risposte, che poi saranno interpretate dal client per fare determinate azioni.
Inoltre, la libreria mette a disposizione una funzione per fare il poll su più socket, e per fare letture non bloccanti.
Vi ringrazio per i suggerimenti e per le risposte a una discussione su un problema (probabilmente) malposto.
*) questa libreria permette di scrivere applicazioni multithread senza usare semafori, mutex e altre "schifezze" simili
edit:
ho scritto multi thread perché la documentazione fa gli esempi espliciti coi thread, ma siccome uso prevalentemente python lato server sto traducendo la cosa in termini di multiprocessing (per via del GIL). In pratica basta cambiare il protocollo da inproc (intra process) usato per comunicare tra thread a ipc (inter processes) usato per comunicare tra processi.
secondo edit:
leggendo ulteriormente la guida, le cose cambiano ulteriormente, perché ci sono indicazioni su come inviare anche il proprio ip nei messaggi, usando una cosa che si chiama "envelope".
In pratica, si possono filtrare i messaggi interessati, con il pattern PUB/SUB.
Inoltre il pattern più indicato per il mio problema non è quello che usavo, ma al momento sto adottando il REQ-ROUTER-queue-DEALER-REP.
E' una sorta di pattern multi thread (sta libreria gestisce anche questioni relative al multithread*, l'hanno pensata gli alieni).
In pratica, quando mi arrivano i dati da REQ, con un thread li carico su un db e con gli altri li analizzo per fare i miei conti, quando questi hanno finito mandano indietro le loro risposte, che poi saranno interpretate dal client per fare determinate azioni.
Inoltre, la libreria mette a disposizione una funzione per fare il poll su più socket, e per fare letture non bloccanti.
Vi ringrazio per i suggerimenti e per le risposte a una discussione su un problema (probabilmente) malposto.
*) questa libreria permette di scrivere applicazioni multithread senza usare semafori, mutex e altre "schifezze" simili
edit:
ho scritto multi thread perché la documentazione fa gli esempi espliciti coi thread, ma siccome uso prevalentemente python lato server sto traducendo la cosa in termini di multiprocessing (per via del GIL). In pratica basta cambiare il protocollo da inproc (intra process) usato per comunicare tra thread a ipc (inter processes) usato per comunicare tra processi.
secondo edit:
leggendo ulteriormente la guida, le cose cambiano ulteriormente, perché ci sono indicazioni su come inviare anche il proprio ip nei messaggi, usando una cosa che si chiama "envelope".
Pirates arrrrrrrrrrr awesome!!!
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
«I fear not the man who has practiced 10000 kicks once,
but I fear the man who has practiced one kick 10000 times.»
Chi c’è in linea
Visualizzano questa sezione: 0 utenti iscritti e 4 ospiti