PROBLEMA [Python] Chat - Problema rete

Andhryss

Nuovo Utente
127
4
Salve a tutti. Sto iniziando a scrivere in Python. Utilizzando le socket, con un amico abbiamo pensato di creare una chat a scopo didattico. Il problema che espongo, attualmente, è concettuale e a livello di rete, non implementativo. Abbiamo scritto due script, Client (che conosce l'indirizzo IP del server) che scrive un messaggio e lo manda al server, mettendosi in attesa della risposta, e un Server che riceve il messaggio e riesce a rispondere. Poche righe di codice per ogni script e il tutto funziona. Ovviamente sotto la stessa sottorete, dove gli IP sono entrambi locali.

Il problema sorge adesso: Se siamo su due sottoreti diverse, supponiamo due LAN distinte, conoscere l'indirizzo IP del Server non mi serve a nulla, dato che quell' IP è locale e riferito alla lan alla quale appartiene la macchina che lo esegue. Ho studiato Reti e conosco i protocolli per richiedere gli IP di altre sottoreti (ARP e quant'altro) ma solo a livello teorico. Riferito al mio problema, come converrebbe operare? (Senza settare ip statici, manomissioni di router e similari)

L'idea di base era far girare lo script server su un Server(macchina) con IP pubblico, di modo che il server potesse fare da tramite per lo scambio dei messaggi. Un alternativa è collegarsi al server che, una volta autenticati i due Client, fornisce loro gli indirizzi per la connessione P2P. E' un idea proponibile?

Ps Ho gia consultato il possibile su Socket e su Python, tutto cio' che ho trovato è riferito alla comunicazione locale, e fin qui funziona.

Grazie per l'attenzione
 

1nd33d

Utente Attivo
653
279
CPU
Intel i5 3570K @ 4,5Ghz
Dissipatore
Scythe Mugen 2
Scheda Madre
Gigabyte Z77X-UD3H
HDD
Samsung 840 PRO 256GB + Sandisk Ultra 250GB + Sandisk Plus 960GB
RAM
2x8GB Crucial Ballistix Tactical @2000Mhz CL9
GPU
XFX RX480 GTR Black Edition
Audio
Auzentech X-Fi Forte
Monitor
AOC i2369VW
PSU
Seasonic P660
Case
eh?
Periferiche
Razer Naga HEX v2
OS
Windows 10 64bit - Linux Mint 18
Devi impostare il NAT sul router per fornire un port-forwarding nella sottorete del server. Il router intercetterà le richieste che arrivano dall'esterno su una determinata porta e le indirizzerà all'ip locale specificato su una data porta. ip-pubblico:porta-pubblica => ip-locale:porta-locale
Non so se questo rientri nella tua definizione di "manomissione" ma è la soluzione più semplice e usata (e rientra tra le basi del networking...). Esiste l'alternativa "automatizzata" che fa la stessa cosa (Upnp NAT) fornita da alcune librerie, ma personalmente preferisco il NAT manuale.
 
Ultima modifica:

Andhryss

Nuovo Utente
127
4
Devi impostare il NAT sul router per fornire un port-forwarding nella sottorete del server. Il router intercetterà le richieste che arrivano dall'esterno su una determinata porta e le indirizzerà all'ip locale specificato su una data porta. ip-pubblico:porta-pubblica => ip-locale:porta-locale
Non so se questo rientri nella tua definizione di "manomissione" ma è la soluzione più semplice e usata (e rientra tra le basi del networking...). Esiste l'alternativa "automatizzata" che fa la stessa cosa (Upnp NAT) fornita da alcune librerie, ma personalmente preferisco il NAT manuale.

Ciao, grazie per la risposta. Effettivamente avevo considerato questa opzione anche se effettivamente non saprei come applicarla, ma sembra che tu abbia fatto un po di luce sulla questione. Nel quote ho evidenziato server. Il port-fowarding quindi deve essere configurato solo sulla sottorete dell host che esegue il processo Server? Se cosi fosse mi puo anche andare bene, alla fine il server è unico e configurato dall'amministrato dell'ipotetica applicazione (chat). Vediamo se ho capito bene:

Il client, che conosce l'ip pubblico della sottorete del server, apre un socket con IpPubblicoServer:NumeroPortaClient e fa la socket.send(). Il server ha impostato il port-forwarding per accettare pacchetti da IPesterni:NumeroPortaServer, dove NumeroPortaServer = NumeroPortaClient e indirizzarli a IPPrivatoServer:NumeroPortaServer.
In questo caso, se il server dovesse rispondere al client con un messaggio (ad esempio un altro client fa uso del server per collegarsi al primo client), conosce l'ip del client? Se si, dovrebbe conoscere quello pubblico, e quindi ripetere la prassi fatta sopra. Il che comporta che anche il client debba configurare il nat.

Se quanto detto sopra è corretto, è improponibile che si chieda all'utente di aprire le porte per poter chattare all'esterno. Dove sbaglio? :pazzo:
 

1nd33d

Utente Attivo
653
279
CPU
Intel i5 3570K @ 4,5Ghz
Dissipatore
Scythe Mugen 2
Scheda Madre
Gigabyte Z77X-UD3H
HDD
Samsung 840 PRO 256GB + Sandisk Ultra 250GB + Sandisk Plus 960GB
RAM
2x8GB Crucial Ballistix Tactical @2000Mhz CL9
GPU
XFX RX480 GTR Black Edition
Audio
Auzentech X-Fi Forte
Monitor
AOC i2369VW
PSU
Seasonic P660
Case
eh?
Periferiche
Razer Naga HEX v2
OS
Windows 10 64bit - Linux Mint 18
Innanzi tutto non è necessario che la porta sull'IP pubblico sia la stessa aperta dal programma.
E no, il client non ha bisogno di essere configurato, solo il server necessita della configurazione, d'altro canto non devi certo impostare il port-forwarding per connetterti al server di un gioco o a un sito web.

Lato server:
Il pc server ha indirizzo locale 192.168.0.2, il router ha indirizzo interno 192.168.0.1 e esterno quello assegnato dall'ISP, per esempio 85.120.70.45.
Il programma server si mette in ascolto su 192.168.0.2:8000. A questo punto, solo i dispositivi della sottorete 192.168.0.0/24 possono connettersi al tuo server sulla porta 8000. Per rendere accessibile il server dall'esterno devi configurare il port-forwarding del router, per esempio impostandolo in modo che le richieste in arrivo su 85.120.70.45:8888 vengano reindirizzate a 192.168.0.2:8000. Il lato server è così configurato.

Lato client:
Non devi far nulla. Il NAT del router del client per le connessioni in uscita funziona in modo automatico. Il client ha IP locale 192.168.1.2 e il router 192.168.1.1.
Il client chiede di collegarsi a 85.120.70.45:8888, il router vede che l'IP destinazione è esterno (non appartiene a 192.168.1.0/24) e quindi indirizza (fa il routing) la richiesta all'esterno. La connessione in uscita dal router client passa per una sua porta esterna scelta dal NAT del router stesso che la memorizza in una tabella. Quando la risposta dal server torna indietro, torna sulla stessa porta e il NAT sa per chi l'aveva aperta e quindi sa a chi spedire la risposta (a 192.168.1.2, appunto).
Il server non deve sapere per forza l'IP del client, in quanto se risponde su una connessione già stabilita, i due router sanno gia come indirizzare il pacchetto.

Questo funziona ovviamente se la connessione è tenuta aperta (in stato di ESTABLISHED). Il server non dovrebbe mai cercare di connettersi ai client, ma solo ricevere le connessioni e usarle per rispondere. Se vuoi implementare un sistema nel quale il server avverte il client dell'arrivo di nuovi messaggi, devi sfruttare altri meccanismi più elaborati, come le notifiche push o un polling attivo da parte del client.
 
Ultima modifica:
  • Mi piace
Reazioni: Andhryss

Andhryss

Nuovo Utente
127
4
Innanzi tutto non è necessario che la porta sull'IP pubblico sia la stessa aperta dal programma.
E no, il client non ha bisogno di essere configurato, solo il server necessita della configurazione, d'altro canto non devi certo impostare il port-forwarding per connetterti al server di un gioco o a un sito web.

Lato server:
Il pc server ha indirizzo locale 192.168.0.2, il router ha indirizzo interno 192.168.0.1 e esterno quello assegnato dall'ISP, per esempio 85.120.70.45.
Il programma server si mette in ascolto su 192.168.0.2:8000. A questo punto, solo i dispositivi della sottorete 192.168.0.0/24 possono connettersi al tuo server sulla porta 8000. Per rendere accessibile il server dall'esterno devi configurare il port-forwarding del router, per esempio impostandolo in modo che le richieste in arrivo su 85.120.70.45:8888 vengano reindirizzate a 192.168.0.2:8000. Il lato server è così configurato.

Lato client:
Non devi far nulla. Il NAT del router del client per le connessioni in uscita funziona in modo automatico. Il client ha IP locale 192.168.1.2 e il router 192.168.1.1.
Il client chiede di collegarsi a 85.120.70.45:8888, il router vede che l'IP destinazione è esterno (non appartiene a 192.168.1.0/24) e quindi indirizza (fa il routing) la richiesta all'esterno. La connessione in uscita dal router client passa per una sua porta esterna scelta dal NAT del router stesso che la memorizza in una tabella. Quando la risposta dal server torna indietro, torna sulla stessa porta e il NAT sa per chi l'aveva aperta e quindi sa a chi spedire la risposta (a 192.168.1.2, appunto).
Il server non deve sapere per forza l'IP del client, in quanto se risponde su una connessione già stabilita, i due router sanno gia come indirizzare il pacchetto.

Questo funziona ovviamente se la connessione è tenuta aperta (in stato di ESTABLISHED). Il server non dovrebbe mai cercare di connettersi ai client, ma solo ricevere le connessioni e usarle per rispondere. Se vuoi implementare un sistema nel quale il server avverte il client dell'arrivo di nuovi messaggi, devi sfruttare altri meccanismi più elaborati, come le notifiche push o un polling attivo da parte del client.

Tutto chiarissimo. In realtà avevo gia provato a configurare il router server in modo simile, o meglio settato il DMZ pensando fosse la stessa cosa, ma avro' sbagliato qualcosa, perchè il client non riusciva comunque a connettersi al server. Si il server non si connette al client ma sfrutta la TCP richiesta dal client giusto? Appena sistemero' gli script faro un test, sperando che non nascano altri problemi :cavallo:

La domanda è stata risolta, ma vorrei lasciare il thread aperto per sentire un parere su un altra questione.
Nell'implementazione della chat, come mi conviene programmare client e server? Nel senso, ho due file .py, client.py e server.py.
Il client verra' eseguito da coloro che vorranno connettersi alla chat e il server ovviamente eseguito da un solo host per gestire le richieste.
L'obiettivo è quello di creare un canale broadcast e a richiesta (il client richiede la lista della coppia IP-Nick connessi) canali p2p. Ho implementato le funzioni Snd e Rcv, seguendo vari script e tutorial in rete attraverso send e rcv del modulo Socket, ma si pone il problema che le due funzioni sono in mutua esclusione, ovvero ricevo solo dopo aver mandato un messaggio. il server.py come dovrebbe gestire le richieste? Crea un thread per ogni socket.accept di ogni client? il client.py come potrebbe contemporaneamente tenere aggiornata la lista dei messaggi nel canale broadcast e poter scrivere?

Spero di essere stato abbastanza chiaro, il problema è prima concettuale, poi implementativo :D
Grazie per la risposta, gentilissimo e chiarissimo
 

signore del tempo

Utente Èlite
3,228
491
CPU
Intel Core i5 4670K
Scheda Madre
Asus Z87-Plus
HDD
WD Caviar Green 500GB
RAM
G.Skill Ares 2x4GB 1600MHz
GPU
Sapphire 7850 1GB @ 1050MHz
Audio
Integrata
Monitor
Acer V193w
PSU
XFX ProSeries 550W Core Edition
Case
CM HAF 912 plus
OS
ArchLinux + KDE - Windows 10
ma si pone il problema che le due funzioni sono in mutua esclusione, ovvero ricevo solo dopo aver mandato un messaggio. il server.py come dovrebbe gestire le richieste? Crea un thread per ogni socket.accept di ogni client?
Che le funzioni siano in mutua esclusione non significa niente: è che il flusso del programma è sincrono e pertanto il funzionamento dell'una preclude l'avvio dell'altra, a causa della loro sequenzialità. Devi implementare una distribuzione dei compiti o col multithreading/tasking* o col IO multiplexing. Il primo è piuttosto semplice da implementare in quanto la concorrenza processuale è piuttosto ristretta se non assente (in base al design, ovviamente), però comunque dovrai usare strutture thread-safe; la seconda ha un meccanismo che può risultare aspro ma è molto potente (socket.select, ad esempio).

Questo se usi TCP, poiché l'UDP supporta il broadcasting effettivo.

*In Python il discorso è un po' diverso a causa del GIL.
 

Andhryss

Nuovo Utente
127
4
Che le funzioni siano in mutua esclusione non significa niente: è che il flusso del programma è sincrono e pertanto il funzionamento dell'una preclude l'avvio dell'altra, a causa della loro sequenzialità. Devi implementare una distribuzione dei compiti o col multithreading/tasking* o col IO multiplexing. Il primo è piuttosto semplice da implementare in quanto la concorrenza processuale è piuttosto ristretta se non assente (in base al design, ovviamente), però comunque dovrai usare strutture thread-safe; la seconda ha un meccanismo che può risultare aspro ma è molto potente (socket.select, ad esempio).

Questo se usi TCP, poiché l'UDP supporta il broadcasting effettivo.

*In Python il discorso è un po' diverso a causa del GIL.
Ciao, grazie per la risposta. Per il multithreading si parla comunque di utilizzare thread e un mutex(semaforo che dir si voglia), e quindi il flusso resta comunque sincrono, o sbaglio? Mi spiego, lato client, ho due thread, un lettore(che legge i messaggi in broadcast) e uno scrittore(che abilita la scrittura, input da tastiera, e invio sul socket). Temporizzando i due thread potrebbe essere una soluzione comunque valida? Ho visto qualcosa in rete con il metodo select, per avere un parallelismo tra scrittura e lettura.
http://steelkiwi.com/blog/working-tcp-sockets/
Potrebbe essere utile al mio scopo?
 

1nd33d

Utente Attivo
653
279
CPU
Intel i5 3570K @ 4,5Ghz
Dissipatore
Scythe Mugen 2
Scheda Madre
Gigabyte Z77X-UD3H
HDD
Samsung 840 PRO 256GB + Sandisk Ultra 250GB + Sandisk Plus 960GB
RAM
2x8GB Crucial Ballistix Tactical @2000Mhz CL9
GPU
XFX RX480 GTR Black Edition
Audio
Auzentech X-Fi Forte
Monitor
AOC i2369VW
PSU
Seasonic P660
Case
eh?
Periferiche
Razer Naga HEX v2
OS
Windows 10 64bit - Linux Mint 18
In python select è molto usato in questi casi. Dalla versione 3.4 esiste anche il modulo selectors che è a un più alto livello, forse più semplice da usare, ma non l'ho mai provato.
 

Andhryss

Nuovo Utente
127
4
In python select è molto usato in questi casi. Dalla versione 3.4 esiste anche il modulo selectors che è a un più alto livello, forse più semplice da usare, ma non l'ho mai provato.
Mi sa che dovro' usarlo, in tutti gli esempi che ho trovato è utilizzato, ma non ho ben capito come.
Ad esempio, script lato server che ho trovato in rete:
Codice:
HOST = socket.gethostbyname(socket.gethostname())
SOCKET_LIST=[]
 server_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 server_sock.bind((HOST,PORT))
 server_sock.listen(10)
 SOCKET_LIST.append(server_sock)

  print("Server della chat inizializzato ed in ascolto sulla porta : " +str(PORT))
  while 1:
        lettore, scrittore, error = select.select(SOCKET_LIST, [], [])
        for sock in lettore:
         if sock == server_sock:
           conn, address = server_sock.accept()
           SOCKET_LIST.append(conn)
           print("Il Client (%s , %s) si e' connesso " % address)
           trasmissione(server_sock, conn, "[%s:%s] e' entrato nella chat room\n" % address)
        else:
                try:
                    data = sock.rcv(RCV_BUFFER)
                    if data:
                            trasmissione(server_sock, sock, "\r" + str(sock.getpeername())+ "> "+data)
                    else:
                         if sock in SOCKET_LIST:
                                    SOCKET_LIST.remove(sock)
                         trasmissione(server_sock, sock, "Il Client (%s, %s) e' uscito..\n" % address)
                except:
                       trasmissione(server_sock, sock, "Il Client (%s, %s) e' uscito..\n" % address)
                       continue
  server_sock.close()

Indentazione da trascurare, non ho ben capito il funzionamento della select, e l'utilità del SOCKET_LIST. Il server crea una socket per ogni client che si collega?

--- Edit ---

Ho provato a mettere insieme quello che ho recepito e riscritto il server più ordinato. I commenti servono a capire se sono sulla giusta strada
Codice:
import socket, threading,time,pickle,select

server_address = ('127.0.0.1',5000) #ip porta
#creo una socket
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.setblocking(0) #non bloccante
server.bind(server_address) #socket collegata alla porta
server.listen(5) #in ascolto di connessioni
inputs = [server] #socket dai quali si attende/aspetta lettura
outputs = [] #socket dai quali si puo' accedere in scrittura
excepts = []
print(server)
print(inputs)
while inputs:
    leggibili,scrivibili,eccezioni  = select.select(inputs,outputs,excepts)
    # select() ritorna tre nuove liste,
    # che contengono sottoinsiemi
    # dei contentuti delle liste ricevute in input
    # Tutti i socket nella list leggibili hanno dati in arrivo nel buffer e sono disponibili per la lettura
    # Tutti i socket della lista scrivibili hanno spazio libero nel loro buffer e vi si può scrivere
    # I socket ritornati in eccezioni hanno avuto un errore

    # I socket "leggibili" rappresentano tre possibili casi. Se il socket è quello principale del server,
    #  quello usato per ascoltare connessioni in arrivo,
    # allora la condizione "leggibile" significa che è pronto ad accettare un'altra connessione in arrivo.
    for sock in leggibili:
        if sock is server:
            # Un socket "leggibile" è pronto ad accettare una connessione
            connection, client_address = sock.accept()
            print('connessione da', client_address)
            connection.setblocking(0)
            inputs.append(connection)
            tmp = bytes("Connesso","ascii")
            #comnunico a tutti che client_address è entrato in stanza
            connection.send(tmp)
        else:
            #siamo in questo caso quando il client ha inviato dei dati e dobbiamo trasmetterli
            #vuol dire che sock in leggibili[] non è quella del server stesso, ma una delle connessioni accettate
            data = sock.recv(4096)
            if data:
                print(data)
                sock.sendall(data)  
            else:
                 if sock in inputs:
                    inputs.remove(sock)
                 connection.send(b"E' uscito qualcuno")
 
Ultima modifica:

signore del tempo

Utente Èlite
3,228
491
CPU
Intel Core i5 4670K
Scheda Madre
Asus Z87-Plus
HDD
WD Caviar Green 500GB
RAM
G.Skill Ares 2x4GB 1600MHz
GPU
Sapphire 7850 1GB @ 1050MHz
Audio
Integrata
Monitor
Acer V193w
PSU
XFX ProSeries 550W Core Edition
Case
CM HAF 912 plus
OS
ArchLinux + KDE - Windows 10
Sì, mi sembri sulla strada giusta. Un paio di consigli non richiesti:

  • Non credo ti interessi che il socket sia scrivibile, caratteristica utilizzata solo in problematiche più complesse, né tantomeno che ci sia un'eccezione (idem). Inoltre, se ci rifletti, il setblocking è del tutto inutile.

#comnunico a tutti che client_address è entrato in stanza
connection.send(tmp)
  • Non credo faccia quello che dici, poiché mandi il buffer al solo peer entrato e non a tutta la lista.

Una volta che hai presi la mano con select e co., potresti muoverti verso framework fatti apposta per ciò; il più notabile di questi è sicuramente Twisted.
 

Andhryss

Nuovo Utente
127
4
Sì, mi sembri sulla strada giusta. Un paio di consigli non richiesti:
Grazie per le dritte, sono sempre ben accette :)

  • Non credo ti interessi che il socket sia scrivibile, caratteristica utilizzata solo in problematiche più complesse, né tantomeno che ci sia un'eccezione (idem). Inoltre, se ci rifletti, il setblocking è del tutto inutile.
Si, potevo lasciarle vuote, ma era brutto lasciare " [ ] " :D

Non credo faccia quello che dici, poiché mandi il buffer al solo peer entrato e non a tutta la lista.
dovrei sostituire " connection " con "sock " dato che sto cliclando nell'array inputs, giusto?
Una volta che hai presi la mano con select e co., potresti muoverti verso framework fatti apposta per ciò; il più notabile di questi è sicuramente Twisted.

Ho dato un occhiata su google cercando la documentazione sul sito ufficiale ma non sono riuscito a comprenderla bene. Penso che per il mio scopo mi atterro' a livelli piu bassi di programmazione.

In ogni caso anche cosi non funziona. Il server legge soltando gli ingressi, si blocca in loop e non riesco a uscire dal terminale con i comandi di escape se non chiudendolo :muro:

Il client dovrebbe essere scritto secondo la stessa logica, con la select giusto? Per avere il "parallellismo" tra scrittura e lettura. Non devo attendere che mi arrivi un messaggio per poterne inviare uno. :pcfury:
 

signore del tempo

Utente Èlite
3,228
491
CPU
Intel Core i5 4670K
Scheda Madre
Asus Z87-Plus
HDD
WD Caviar Green 500GB
RAM
G.Skill Ares 2x4GB 1600MHz
GPU
Sapphire 7850 1GB @ 1050MHz
Audio
Integrata
Monitor
Acer V193w
PSU
XFX ProSeries 550W Core Edition
Case
CM HAF 912 plus
OS
ArchLinux + KDE - Windows 10
dovrei sostituire " connection " con "sock " dato che sto cliclando nell'array inputs, giusto?
Devi fare (magari in una funzione a parte) un for-in su tutte le connessioni e mandare singolarmente il messaggio. Una cosa del tipo:
Codice:
def broadcast(msg, peers):
      for p in peers:
           p.send( bytes(msg, 'utf-8') )
In ogni caso anche cosi non funziona. Il server legge soltando gli ingressi, si blocca in loop e non riesco a uscire dal terminale con i comandi di escape se non chiudendolo
Mi sembra normale; se vuoi che venga letto anche l'input, devi passare sys.stdin anche nella input list. Ovviamente andrà gestito separatamente. NB per Windows dalla documentazione di select:
*** IMPORTANT NOTICE ***
On Windows, only sockets are supported; on Unix, all file
descriptors can be used.
Il client dovrebbe essere scritto secondo la stessa logica, con la select giusto?
Yep.
 
Ultima modifica:

Andhryss

Nuovo Utente
127
4
Devi fare (magari in una funzione a parte) un for-in su tutte le connessioni e mandare singolarmente il messaggio. Una cosa del tipo:
Codice:
def broadcast(msg, peers):
      for p in peers:
           p.send( bytes(msg, 'utf-8') )

Mi sembra normale; se vuoi che venga letto anche l'input, devi passare sys.stdin anche nella input list. Ovviamente andrà gestito separatamente. NB per Windows dalla documentazione di select:


Yep.

Si dovrei aver sistemato, e il server funziona grazie. Ad ogni connessione accettata manda una stringa (Name: ) e il prossimo messaggio ricevuto sarà salvato in un dizionario (socket : "Name") Per avere un Nick invece che un Ip:Porta Nella visualizzazione. Fin qui tutto bene.
Vorrei pero' complicare un po' le cose. Mi piacerebbe inserire un Log in o Registrazione, per farlo mi converrebbe scrivere un altro script server_auth.py ad esempio?
Ho visto qualcosa con Oauth per autenticarmi direttamente con email e pass di google(esempio) ma la documentazione della libreria per python è troppo dispersiva, non trovo nessun esempio utile. Per questo pensavo di scrivere un server dedicato solo all'autorizzazione e poi rimandare il client al server di chat...che te ne pare?
 

signore del tempo

Utente Èlite
3,228
491
CPU
Intel Core i5 4670K
Scheda Madre
Asus Z87-Plus
HDD
WD Caviar Green 500GB
RAM
G.Skill Ares 2x4GB 1600MHz
GPU
Sapphire 7850 1GB @ 1050MHz
Audio
Integrata
Monitor
Acer V193w
PSU
XFX ProSeries 550W Core Edition
Case
CM HAF 912 plus
OS
ArchLinux + KDE - Windows 10
OAuth mi sembra un po' eccessivo. Oltretutto, senza un canale crittografato non fai nulla; e lì le cose cominciano a dilungarsi. Personalmente, passerei alla stesura di un protocollo in modo che hai una base laddove vuoi trasmettere informazioni eterogenee (già l'hard-coded 4096 bytes è meh). Poi a qualche framework più high-level -non che il tuo sia sbagliato, si intenda-, sempre per avere basi migliori di sviluppo: come indicavo prima, Twisted et similia. Se vuoi avere degli utenti, dovrai avere qualche forma di database: probabilmente SQLite è la miglior scelta.

Per le features, puoi sempre prendere nota da chat notevoli e.g. IRC.
 

Andhryss

Nuovo Utente
127
4
OAuth mi sembra un po' eccessivo. Oltretutto, senza un canale crittografato non fai nulla; e lì le cose cominciano a dilungarsi. Personalmente, passerei alla stesura di un protocollo in modo che hai una base laddove vuoi trasmettere informazioni eterogenee (già l'hard-coded 4096 bytes è meh). Poi a qualche framework più high-level -non che il tuo sia sbagliato, si intenda-, sempre per avere basi migliori di sviluppo: come indicavo prima, Twisted et similia. Se vuoi avere degli utenti, dovrai avere qualche forma di database: probabilmente SQLite è la miglior scelta.

Per le features, puoi sempre prendere nota da chat notevoli e.g. IRC.

Si infatti mi sa che abbandonero' l'idea di OAuth, l'intento del progetto è solo quello di prendere familiarità con la sintassi del linguaggio, provero' soltanto a inserire un autenticazione tramite interazione con il db, qualche semplice query e nulla di piu. Grazie per le dritte finora, il thread magari resta aperto per qualche altro eventuale dubbio :)
 

Ci sono discussioni simili a riguardo, dai un'occhiata!

Entra

oppure Accedi utilizzando
Discord Ufficiale Entra ora!

Discussioni Simili