Buongiorno a Tutti,sono abbastanza ignorante in materia.Ho provato a seguire alcune guide trovate in rete ma non sono riuscito risolver il mio problema.
Sto sviluppando un programma che interagisce, via ethernet, con un macchinario che monta un server phyton.
ho provato ad assemblare un piccolo script server (attingendo da script in rete) ,su lan, con python 2.7 (quello che monta il sistema) e fuziona discretamente (per le mie esigenze)
Il mio problema è che quando esco dal mio programma, lo script di py rileva una interruzione del socket,mi chiede di schiacciare un tasto e si chiude. a quel punto devo far ripartire lo script.
Non è che voglio la pappa pronta,ho provato diversi tentativi,ma non sono riuscito a risolvere.

Qualcuno mi potrebbe venire in aiuto correggendo /implementando il mio codice con la parte che mi serve?
In pratica, all'errore mi sta bene in messaggio ma se schiaccio il tasto,ritenta la connessione finche non è ripristinata.
Grazie a chiunque mi possa dare una mano
ps...questa riga dello script, sotto, è ripotata male (no parentesi quadre ma simboli) questa è la sintassi corretta > str(msg"parentesi quadra"0"chiude parentesi quadra" + ' Message ' + msg"parentesi quadra"1"chiude parentesi quadra"]

Mario

'''
	Simple socket server using threads
'''
import socket
import sys
import time

HOST = "192.168.0.18"	# Symbolic name, meaning all available interfaces
PORT = 49280	# Arbitrary non-privileged port

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print 'Socket attivato'

#Bind socket to local host and port
try:
	s.bind((HOST, PORT))
except socket.error as msg:
	print 'Bind failed. Error Code : ' + str(msg0) + ' Message ' + msg1# questa riga è riportata senza le parentesi quadre
	#sys.exit()
	
	
print 'Link socket completato'

#Start listening on socket
#s.listen(10)
print 'In attesa....'

#now keep talking with the client
while 1:
	s.listen(10)
	
    #wait to accept a connection - blocking call
	conn, addr = s.accept()
	condition = True
	while condition:
		data=conn.recv(1024)
		#print 'Connected with ' + addr0 + ':' + str(addr1 )+repr(data)
		print 'Connected with ' + addr0 + ':' + str(addr1 )
		print  repr(data)
		stringa=repr(data)
		mystring='ssrecal'
		myok='NOTIFY sscurrent_ex '
		r='OK ' + (data)
		conn.send(r.encode())

		if mystring in stringa:
					print(">>>>>>-------Procedura richiamo scena") 
					time.sleep(300/1000)
					#print(stringa[-12:])
					myok=myok + (stringa[-12:])
					conn.send (myok.encode())
		
	#s.close()

Ciao @mario, è da ieri che guardo questo post, speravo che intervenisse qualche utente più esperto di me, vedo che non è così, pertanto provo a darti "qualcosa" io.

Premetto che in python ci ho lavorato poco con i socket (in altri linguaggi di più), comunque mi duole dirTi che con i socket non te la cavi mica con qualche riga di codice copiata qui e la in rete, i protocolli di rete sono delle bestioline complicate e sottendono solide strategie di progettazione per poterli affrontare, in rete si trovano per lo più banalità per un argomento che richiederebbe libri interi, ho cercato di trovare qualcosa che possa renderTi idea, ho trovato un tutorial che penso sia "passabile", Ti inviterei a leggerlo per intero ed a fare delle prove, non è esaustivo ma forse la parte che tratta del multithreading Ti fornirà qualche indizio di possibile soluzione del Tuo problema.




Riguardo la "integrazione" del Tuo codice, non ci provo neanche, intanto non ho installato python 2.7, ormai desueto da tempo, che macchinario è quello che utilizzi? sicuro non vi sia una una versione di python 3 su di essa?

In secondo luogo il protocollo TCP-IP (parametri socket.AF_INET e socket.SOCK_STREAM) non garantisce che un messaggio venga recapitato tutto in una volta, quindi che basti un unico "recv(size)" per recuperarlo per intero, puoi vedere qui domande relative che mi son posto anni fa, esistono tutta una serie di problematiche che bisogna considerare ed affrontare per poter fare le cose "per bene", problematiche di cui devi renderTi edotto per poter affrontare l'argomento socket.




Con quanto sopra non voglio scoraggiarTi ma solo darti un indizio per l'avvio sull'argomento, se ritieni se ne parla e, magari, si abbozza assieme qualche prova per chiarire assime qualche aspetto.




Ciao

ciao @nuzzopippo.
Ti ringrazio per il replay.
Io python non lo
uso,ma purtroppo ho a che fare con una periferica audio pro yamaha che
monta....un st32 (hanno cancellato le sigle e modificato un po le
schede interne pensando che cosi...davano l'idea di una cosa tutta loro ma non sono riuscuti ) con
caricato py 2.7 ( o cmq vecchio)
Purtroppo la periferica non è mia e quindi i test non posso farli facilmente
Personalmente
sviluppo in VB e PHP ,e dato che sono riuscito a recuperare il service manual
ed il develop datasheet ,mi sono gia fatto un server ad hoc nei miei ambienti, per testare
le comunicazioni via lan.
Con il mio server funziona
tutto ma volevo provare con Py per avere conferma che tutto andasse bene
perchè purtroppo , come penso tu sappia, le codifice e decodifiche
delle stringhe in byte sono tutte uguali al 99.99999% e la sfiga...vuol
dire che a me capita il famoso 0.00001%!!
Figurati che da UNICODE a
FROMUNICODE viene tolto lo 0X finale...che non viene letto, ma se leggi
la stringa al contrario, la lunghezza in byte è differente...di un byte e
nel caso di controlli di lunghezza....ti frega!
Pensavo che anche in
Py ,abilitado il multiprocesso,ci fosse una sorta di "on error etc
etc"...che in effetti esiste (Sotto altri termini >> TRY) ma
purtroppo le differenza sintattiche rispetto ai programmi che uso io, e
capire dove mettere e se mettere una virgola anziche un apice o un due
punti...mi hanno fatto perdere tanto tempo e pazienza.
E' cosi che sono arrivato a questa richiesta.
Se
qualche anima pia riesce ad inserirmi questa procedura TRY ne sarei
grato...se no pace...continuo con il mio sviluppo che all 99,99999999 %
funziona. se capita la sfiga....ci pensero con wireshark a decodificare i byte trovare questo 0.000001 malefico!!
Grazie cmq per l'interessamento.
Mario

Capisco, diciamo che con le codifiche prima o poi ci sbattiamo un po' tutti le corna, partendo già dalla codifica dei bit a livello hardware

La endianness (ordine dei byte) di un computer dipende essenzialmente dall'architettura hardware usata. Ad esempio, Intel e Digital usano il formato little endian mentre Motorola, IBM e Sun usano il formato big endian. Il formato dei dati contenuti nelle intestazioni dei protocolli di rete è anch'esso big endian; altri esempi di uso di questi due diversi formati sono quello del bus PCI, che è little endian, o quello del bus VME che è big endian.

argomento su cui è molto difficile implementare soluzioni del 100%, anche con python.




Riguardo al Tuo problema, per quanto possano esserci persone di buon cuore è molto difficile qualcuno si avventuri a sviluppare "soluzioni" senza specifiche ben chiare e per si più con versioni obsolete del linguaggio e per singolo hardware ... tralasciando la problematica "codifica", in soldoni, se ho compreso bene a Te serve tanto che il "server" non chiuda la sessione non appena viene chiusa la connessione dal client, in sostanza devi creare quello che in ambiente unix-like viene chiamato un "daemon", in sostanza, per farlo, bisognerebbe aprire un thread per il client e farlo agire separatamente dal processo principale, con un suo buffer per i dati e le operazioni relative, non è un blocco try-catch-finally che risolverebbe.




Mi son fatto una carrellata dei Tuoi post, ho visto che non utilizzi python ma il VB6 e che lo usi anche abbastanza bene a qual che leggo, se python ti serve solo per una conferma circa l'encoding non credo che risolverai, a quanto visto anche con python affrontare le varie "codifiche" è complicato.

Qualora poi Tu decida di affrontare il problema della Tua scheda con python, dovresti applicare una logica tipo quella contenuta in questo articolo, forse ancora semplicistica ma l'idea è quella.




Ciao

Si...tra indiani "grandi e piccoli" e "dialetti"...se ne vedono di tutti i colori.
Diciamo che il mio era un "di piu",perche ad ora tutte le stringhe che ho usato sono state lette ed interpretate correttamente dalla periferica.
Volevo provare il discorso Py per non sentirmi dire "...è...allora è un problema da parte del tuo programma.." ma,ripeto, ad ora,tutto è filato per i verso giusto, il famoso 0,00000001% l'ho risolto usando wireshark e tanta pazienza.
Si , sviluppo su Vb6 ,e magari anche questo, con la gestione lan e byte, non è proprio una cima.
Ma devo dire che fino ad ora, per i miei utilizzi, sono riuscito a fare tutto quello che mi è stato richiesto (ovvio...spesso con gran penare!!!).
Ho provato a "migrare" verso altri sistemi piu recenti ma...sinceramente...li ho trovati molto cervellotici e pesanti (anche per le macchine su cui vanno installati gli sviluppi).
Diciamo che restando nel mio piccolo antro di php/c e vb6...riesco a far dialogare assieme macchine di 30 anni fa e le loro nipoti di nuova generazione.
FInchè dura...va bene,poi...si vedrà!
Grazie comunque per la chiacchierata e gli spunti !!
Mario

Si...tra indiani "grandi e piccoli" e "dialetti"...se ne vedono di tutti i colori.
Diciamo che il mio era un "di piu",perche ad ora tutte le stringhe che ho usato sono state lette ed interpretate correttamente dalla periferica.
Volevo provare il discorso Py per non sentirmi dire "...è...allora è un problema da parte del tuo programma.." ma,ripeto, ad ora,tutto è filato per i verso giusto, il famoso 0,00000001% l'ho risolto usando wireshark e tanta pazienza.
Si , sviluppo su Vb6 ,e magari anche questo, con la gestione lan e byte, non è proprio una cima.
Ma devo dire che fino ad ora, per i miei utilizzi, sono riuscito a fare tutto quello che mi è stato richiesto (ovvio...spesso con gran penare!!!).
Ho provato a "migrare" verso altri sistemi piu recenti ma...sinceramente...li ho trovati molto cervellotici e pesanti (anche per le macchine su cui vanno installati gli sviluppi).
Diciamo che restando nel mio piccolo antro di php/c e vb6...riesco a far dialogare assieme macchine di 30 anni fa e le loro nipoti di nuova generazione.
FInchè dura...va bene,poi...si vedrà!
Grazie comunque per la chiacchierata e gli spunti !!
Mario