[Risolto] Non usare quella porta

Linguaggi di programmazione: php, perl, python, C, bash e tutti gli altri.
Scrivi risposta
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

[Risolto] Non usare quella porta

Messaggio da vaeVictis »

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 :ciao:
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.»
korda
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1703
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Non usare quella porta

Messaggio da korda »

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?)
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

Re: Non usare quella porta

Messaggio da vaeVictis »

korda ha scritto:
lunedì 29 novembre 2021, 17:22
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?
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?
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?)
Temo che questo non sia fattibile. Ci rifletto un po' e ti faccio sapere.
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.»
korda
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1703
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Non usare quella porta

Messaggio da korda »

vaeVictis ha scritto:
lunedì 29 novembre 2021, 19:24
korda ha scritto:
lunedì 29 novembre 2021, 17:22
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?)
Temo che questo non sia fattibile. Ci rifletto un po' e ti faccio sapere.
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.
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

Re: Non usare quella porta

Messaggio da vaeVictis »

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.
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.»
Avatar utente
nuzzopippo
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1623
Iscrizione: giovedì 12 ottobre 2006, 11:34

Re: Non usare quella porta

Messaggio da nuzzopippo »

vaeVictis ha scritto:
martedì 30 novembre 2021, 0:00
... Mi sa che mi devo rileggere la documentazione di ZMQ.
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 ...
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

Re: Non usare quella porta

Messaggio da vaeVictis »

nuzzopippo ha scritto:
martedì 30 novembre 2021, 10:58
vaeVictis ha scritto:
martedì 30 novembre 2021, 0:00
... Mi sa che mi devo rileggere la documentazione di ZMQ.
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.
Sì, infatti la domanda specifica che ho fatto era per ampliare il discorso che abbiamo fatto in quell'altra discussione :)
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.»
korda
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1703
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Non usare quella porta

Messaggio da korda »

vaeVictis ha scritto:
martedì 30 novembre 2021, 0:00
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.
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.
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
Avatar utente
nuzzopippo
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1623
Iscrizione: giovedì 12 ottobre 2006, 11:34

Re: Non usare quella porta

Messaggio da nuzzopippo »

vaeVictis ha scritto:
martedì 30 novembre 2021, 11:19
Sì, infatti la domanda specifica che ho fatto era per ampliare il discorso che abbiamo fatto in quell'altra discussione :)
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 ...
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

Re: Non usare quella porta

Messaggio da vaeVictis »

@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

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")

e a questo per il client

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} ]")
In pratica il client manda stringhe

Codice: Seleziona tutto

Hello number N from NOME_CLIENT
il server le riceve e risponde con la stessa stringa più la string " | World"

Codice: Seleziona tutto

Hello number N from NOME_CLIENT | 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.
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.»
Avatar utente
Claudio_F
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1463
Iscrizione: lunedì 28 maggio 2012, 18:49
Desktop: Mate/Gnome
Distribuzione: Ubu22.04

Re: Non usare quella porta

Messaggio da Claudio_F »

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.
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.
Avatar utente
nuzzopippo
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1623
Iscrizione: giovedì 12 ottobre 2006, 11:34

Re: Non usare quella porta

Messaggio da nuzzopippo »

vaeVictis ha scritto:
martedì 30 novembre 2021, 14:04
@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.
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()
ed il codice manipolato per i client:

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()
... come puoi vedere, sono stato rozzo e diretto, implementando un odore di protocollo (identify e quit) per le comunicazioni e certo manca qualche accorgimento relativo alla lib zmq, che mi ha costretto a chiusure brutali della applicazione ma ho visto che l'identificazione è possibilissima, vedi gli output che seguono, e che zmq gestisce in un qualche modo i messaggi concorrenti da più indirizzi, abche se l'indicazione di @Claudio_F non perde nulla del suo valore, dato che è comunque quella la modalità di gestione.

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:~$ 
Output di connessione da localhost, qui si è provato il riconoscimento

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:~$
Come puoi vedere nel primo tentatico, con ID server errato la disconnessione è stata immediata

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:~$
dagli output puoi vedere che ad ogni client è arrivata la risposta "giusta", entrambi i client rimangono con dei job appesi per la chiusura brutale (non saprei il server) ma l'insieme funziona e non ho di certo adottato il criterio REQ/REP, solo una brutale scrittura dell'input utente e delle risposte pre-ordinate :D

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 :birra:
Fatti non foste a viver come bruti ...
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

Re: Non usare quella porta

Messaggio da vaeVictis »

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 :D
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.»
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

Re: Non usare quella porta

Messaggio da vaeVictis »

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 :lol:
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.»
Avatar utente
nuzzopippo
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1623
Iscrizione: giovedì 12 ottobre 2006, 11:34

Re: Non usare quella porta

Messaggio da nuzzopippo »

vaeVictis ha scritto:
mercoledì 1 dicembre 2021, 14:56
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.
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 ...
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

Re: Non usare quella porta

Messaggio da vaeVictis »

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
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.»
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

Re: Non usare quella porta

Messaggio da vaeVictis »

Claudio_F ha scritto:
martedì 30 novembre 2021, 14:47
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.
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.
Ciao @Claudio_F, mi era sfuggito il tuo intervento.
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.»
Avatar utente
vaeVictis
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 4703
Iscrizione: venerdì 27 luglio 2012, 17:58
Desktop: Gnome
Distribuzione: Ubuntu 20.04 64bit

Re: Non usare quella porta

Messaggio da vaeVictis »

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.

:ciao:

*) questa libreria permette di scrivere applicazioni multithread senza usare semafori, mutex e altre "schifezze" simili :o

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.»
Scrivi risposta

Ritorna a “Programmazione”

Chi c’è in linea

Visualizzano questa sezione: 0 utenti iscritti e 4 ospiti