Tempo di riconnessione al server da FB TCP Client
Home › Forum › Controllori SlimLine e Netsyst (LogicLab) › Tempo di riconnessione al server da FB TCP Client
- Questo topic ha 7 risposte, 3 partecipanti ed è stato aggiornato l'ultima volta 8 anni, 11 mesi fa da
Sergio Bertana.
-
AutorePost
-
Febbraio 18, 2016 alle 3:14 pm #35953
Maurizio Conti
PartecipanteStò utilizzando il FB SysTCPClient per connettermi ad un server TCP (Utilizzo Toolly come server), in pratica ho utilizzato il programma dimostrativo che è riportato sul manuale.
Noto che se chiudo la connessione lato server, quando la riapro, lo SlimLine non è immediato nel riconnettersi, ma passa un tempo variabile che può arrivare anche a parecchi secondi. Siccome il comando di Connect del FB è sempre attivo mi aspetto che la riconnessione sia immediata. Dove sbaglio ?
Febbraio 18, 2016 alle 3:25 pm #39399Sergio Bertana
Amministratore del forumHo fatto delle prove ed in effetti ho visto che se la connessione del FB client ha la porta fissata (Come nell’esempio FBD), il PC non accetta la riconnessione immediata. Se tu utilizzi Wireshark ed analizzi la rete, vedrai che lo SlimLine invia il pacchetto di apertura connessione ma il PC lo rifiuta.
La soluzione al problema è lasciare libera la porta da cui il client effettua la connessione TCPClient.LocalPort:=0; in questo modo ad ogni riconnessione il client cambia la sua porta ed il PC vedendo arrivare la connessione da una nuova porta la accetta immediatamente.
Ti ricordo comunque che vi è un tempo di riconnessione cablato nel FB SysTCPClient di circa 10 secondi, se vuoi evitare questo tempo ed avere la riconnessione immediata devi gestire il comando di Connect da programma. Ecco come ho fatto:
IF (TCPClient.Connected <> OneShot) THEN
OneShot:=TCPClient.Connected;
IF NOT(TCPClient.Connected) THEN TCPClient.Connect:=FALSE; END_IF;
END_IF;TCPClient(); (* TCPClient management *)
TCPClient.Connect:=TRUE; (* Connect command *)In questo modo come vedi appena il client si disconnette disabilita per un loop il comando di Connect per poi riabilitarlo. Ecco la stampa del programma ed il progetto per il download.
Febbraio 19, 2016 alle 10:23 am #39400Sergio Bertana
Amministratore del forumHo eseguito una modifica al programma precedente anzichè testare il fronte di disattivazione del TCPClient.Connected ho inserito un timer. In questo modo si è certi di controllare lo stato di TCP client disconnesso e di disabilitare per un loop il FB per forzare la riconnessione. Ecco la stampa del programma ed il progetto per il download.
Febbraio 19, 2016 alle 2:53 pm #39401Maurizio Conti
PartecipanteMille grazie dell’aiuto! Il sistema così concepito funziona molto bene.
Febbraio 23, 2016 alle 9:06 am #39409Maurizio Conti
PartecipanteSegnalo una piccola sbavatura. Dopo diverse ore che il sistema stava operando, pur risultando il flag di connected=TRUE e fault=FALSE (cioè situazione normale), ho riscontrato assenza di flusso di dati sul TCP Client. Ho riavviato il server… Mi aspettavo di vedere nella finestra di watch un palleggio sui tentativi di connessione ma invece il flag di connected sempre TRUE (in quel momento il server si stava riavviando, quindi penso che Connected riportasse uno stato non corretto…).
Per sbloccare la situazione ho dovuto, dalla finestra di watch, forzare manualmente la riconessione lato Client ponendo CONNECT=FALSE e tutto è ripartito (cioè i dati sono ricominciati a fluire). Quindi nell’applicazione mi sembra che il solo check sul flag Connected per rifare la connessione sia un pò debole, se questo non è assolutamente affidabile (socket appeso??).
Rimane sempre la considerazione che, vista la rapidità con cui la connessione può essere ripristinata, è probabilmente più sicuro, a fronte di un modesto rischio di perdere qualche dato inviato dal server, periodicamente chiudere e riaprire il TCPClient.
Febbraio 23, 2016 alle 10:19 am #39410Sergio Bertana
Amministratore del forumNon mi dici se lato client esegui l’invio di dati al server… perchè se non c’è invio di dati tutto quello che hai descritto è normale in una comunicazione TCP/IP. Il client dopo aver terminato la three way connection attiva Connected e non ha nessun altro metodo per capire che la connessione è attiva.
Se il server chiude la connessione allora riceve un pacchetrto di chiusura e se ne accorge ma se tagli il cavo, ammazzi il processo server, o qualsiasi altra ipotesi che non sia la chiusura corretta della connessione non può essere gestita dal client. Non so cosa vuol dire riavviare il server ma se vuol dire spegnerlo e riaccenderlo ancora una volta il client non può accorgersene.
Ecco perchè non mi stufo mai di dire che se si desidera avere la certezza che client e server siano effettivamente connessi deve sempre essere inviato dal client un pacchetto dati verso il server ed allora si che il FB sulla mancata consegna del pacchetto può accorgersi che non è più connesso…
Il TCP/IP è così… una volta aperta la connessione se non ci si parla il socket vive nell’ignoranza…
Maggio 10, 2016 alle 1:29 pm #39565Emiliano
PartecipanteSalve, sto provando ad utilizzare il socket Client il tutto funziona correttamente se non spengo la slimline per lunghi periodi, nella Back ho questo codice:
IF SysFirstLoop THEN
Client.PeerAdd:=ADR(‘192.168.1.40’); (* Peer address *)
Client.PeerPort:=1212; (* Peer port *)
Client.LocalAdd:=ADR(‘0.0.0.0’); (* Local address *)
Client.LocalPort:=0; (* Local port *)
Client.FlushTm:=50; (* Flush time (mS) *)
Client.LifeTm:=120; (* Life time (S) *)
Client.RxSize:=128; (* Rx buffer size *)
Client.TxSize:=128; (* Tx buffer size *)
END_IF;Client(Connect:=TRUE); (* TCPClient management *)
Fp:=Client.File; (* File pointer *)IF (Send)THEN
IF (Client.Connected ) THEN (* TODO *) END_IF;
END_IF;In condizioni normali con server (Toolly) in ascolto ho: Client.Connect=TRUE Client.Connected=TRUE Fp=valore.
Se spengo e riaccendo lo SlimLine si riconnette senza problemi, ma se la riaccendo es dopo un’ora c.a (o il giorno dopo) ho: Client.Connect=TRUE Client.Connected=FALSEFp=0 costringendomi a ricaricare il programma. Dove sbaglio, mi sfugge qualcosa ?Maggio 12, 2016 alle 8:13 am #39566Sergio Bertana
Amministratore del forumHai eseguito l’upgrade all’ultima versione del sistema operativo (Vedi FAQ) ? Dalla versione SFW184B020 abbiamo risolto un bug.
Risolto bug del SysTCPClient: sul Connect, a volte non effettua la connessione. -
AutorePost
- Devi essere connesso per rispondere a questo topic.