Info TCP server

[md9327]

In realtà sulle porte, i problemi potresti incontrarli tra le macchine e non con le utenze sulla stessa...
Questo a meno che la porta non sia attualmente usata da qualche altro servizio...

[El Berto]

La porta era stata scelta 29 proprio perchè era libera, e in Windows ha sempre funzionato.
I problemi li ho incontrati passando con Gambas (Ubuntu).
Poi ho provato oggi, giusto per sfizio, a lanciare il server come root, sulla porta 29 e non mi ha più messo errore.
Se però lancio Gambas come sudo, allora il server parte sulla porta 29, ma dall'esterno non riesco a collegarmi.
Il firewall è disabilitato.
C'è qualche modo per vedere i processi e le porte che eventualmente utilizzano?

[pastrank]

La porta era stata scelta 29 proprio perchè era libera, e in Windows ha sempre funzionato.
I problemi li ho incontrati passando con Gambas (Ubuntu).

Sotto la 1024 se e' un processo utente, non viene permesso: e' forse un tentativo di aumentare la sicurezza retaggio del passato, ma tant'e' , non ti viene permesso.

[El Berto]

Allora, non sono riuscito a cambiare la porta TCP.
L'unica cosa che mi rimaneva da fare è quella di lanciare il server come utente root.

Riesco correttamente a ricevere i dati, tutto contento....... e poi si ferma tutto.
Come se non mi arrivasse più niente.
Provo a chiedere i log del traffico al sistemista e lui mi conferma che i pacchetti arrivano alla mia macchina.
Solo che, anche se metto dei breakpoint all'interno del programma, non succede niente.

E'possibile che vi sia un qualche genere di bug, magari risolto in Gambas3?
La cosa che non capisco è che usando la porta 2000 funziona perfettamente.....

[pastrank]

Allora, non sono riuscito a cambiare la porta TCP.

Ovvero? Intendi questo?

Server.Port = 27 ' porta

[El Berto]

No, intendo dire che per campiare la porta TCP devo andare fisicamente su tutti i client, ricompilare con una porta TCP diversa dalla 29 e riscrivere il firmware.
Quindi devo per forza riuscire a lavorare con un server sulla porta 29.

Proprio non capisco perchè mi da problemi la porta 29 (con la 2000 funziona sempre); addirittura sono costretto a riavviare il computer perchè poi mi ricompare "unable to bind socket".

[El Berto]

Magari voi ci capite qualcosa.

Acquisizione fatta con wireshark 1.6.8 su Windows, server TCP porta 29:

Codice: [Seleziona]

      9 11:25:20.0 192.168.81.220        158.110.30.62         TCP      60     ismc > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     10 11:25:20.0 158.110.30.62         192.168.81.220        TCP      58     msg-icp > ismc [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
     11 11:25:20.0 192.168.81.220        158.110.30.62         TCP      60     ismc > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
     12 11:25:20.0 192.168.81.220        158.110.30.62         TCP      106    ismc > msg-icp [PSH, ACK] Seq=1 Ack=1 Win=32 Len=52
     13 11:25:20.0 158.110.30.62         192.168.81.220        TCP      62     msg-icp > ismc [PSH, ACK] Seq=1 Ack=53 Win=65483 Len=8
     14 11:25:20.0 192.168.81.220        158.110.30.62         TCP      60     ismc > msg-icp [ACK] Seq=53 Ack=9 Win=32 Len=0

Acquisizione fatta con wireshark 1.2.11 su Ubuntu, server TCP porta 29 (esempio funzionante):

Codice: [Seleziona]

      9 11:44:05.6 192.168.81.220        158.110.30.62         TCP      cert-initiator > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     10 11:44:05.6 158.110.30.62         192.168.81.220        TCP      msg-icp > cert-initiator [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
     11 11:44:05.6 192.168.81.220        158.110.30.62         TCP      cert-initiator > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
     12 11:44:05.7 192.168.81.220        158.110.30.62         TCP      cert-initiator > msg-icp [PSH, ACK] Seq=1 Ack=1 Win=32 Len=52
     13 11:44:05.7 158.110.30.62         192.168.81.220        TCP      msg-icp > cert-initiator [ACK] Seq=1 Ack=53 Win=5840 Len=0
     14 11:44:05.8 158.110.30.62         192.168.81.220        TCP      msg-icp > cert-initiator [PSH, ACK] Seq=1 Ack=53 Win=5840 Len=8
     15 11:44:05.9 192.168.81.220        158.110.30.62         TCP      cert-initiator > msg-icp [ACK] Seq=53 Ack=9 Win=32 Len=0

Acquisizione fatta su Ubuntu, quando si presenta il problema:

Codice: [Seleziona]

     13 19:32:07.9 192.168.81.220        158.110.30.62         TCP      60     4290 > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     14 19:32:07.9 192.168.81.220        158.110.30.62         TCP      60     4290 > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
     15 19:32:08.0 192.168.81.220        158.110.30.62         TCP      106    4290 > msg-icp [PSH, ACK] Seq=1 Ack=1 Win=32 Len=52
     16 19:32:08.4 192.168.81.220        158.110.30.62         TCP      60     4290 > msg-icp [ACK] Seq=53 Ack=9 Win=32 Len=0
(trasmissione funzionante) 

     45 19:50:55.1 192.168.81.220        158.110.30.62         TCP      60     4291 > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     46 19:50:55.1 192.168.81.220        158.110.30.62         TCP      60     4291 > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
     47 19:50:55.2 192.168.81.220        158.110.30.62         TCP      106    4291 > msg-icp [PSH, ACK] Seq=1 Ack=1 Win=32 Len=52
     48 19:50:55.5 192.168.81.220        158.110.30.62         TCP      60     4291 > msg-icp [ACK] Seq=53 Ack=9 Win=32 Len=0
(ultima trasmissione funzionante)
 
     69 20:09:42.3 192.168.81.220        158.110.30.62         TCP      60     4292 > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     70 20:09:42.3 192.168.81.220        158.110.30.62         TCP      60     4292 > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
     71 20:09:42.4 192.168.81.220        158.110.30.62         TCP      106    4292 > msg-icp [PSH, ACK] Seq=1 Ack=1 Win=32 Len=52
     72 20:09:42.4 192.168.81.220        158.110.30.62         TCP      60     4292 > msg-icp [FIN, ACK] Seq=53 Ack=2 Win=32 Len=0
     73 20:09:42.4 192.168.81.220        158.110.30.62         TCP      60     4292 > msg-icp [RST] Seq=54 Win=32 Len=0
     74 20:09:42.4 192.168.81.220        158.110.30.62         TCP      60     4293 > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     75 20:09:42.4 192.168.81.220        158.110.30.62         TCP      60     4293 > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
     76 20:09:42.5 192.168.81.220        158.110.30.62         TCP      106    4293 > msg-icp [PSH, ACK] Seq=1 Ack=1 Win=32 Len=52
     77 20:09:42.5 192.168.81.220        158.110.30.62         TCP      60     4293 > msg-icp [FIN, ACK] Seq=53 Ack=2 Win=32 Len=0
     78 20:09:42.5 192.168.81.220        158.110.30.62         TCP      60     4294 > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     79 20:09:42.5 192.168.81.220        158.110.30.62         TCP      60     4293 > msg-icp [RST] Seq=54 Win=32 Len=0
     80 20:09:42.5 192.168.81.220        158.110.30.62         TCP      60     4294 > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
     81 20:09:42.5 192.168.81.220        158.110.30.62         TCP      106    4294 > msg-icp [PSH, ACK] Seq=1 Ack=1 Win=32 Len=52
     82 20:09:42.5 192.168.81.220        158.110.30.62         TCP      60     4294 > msg-icp [FIN, ACK] Seq=53 Ack=2 Win=32 Len=0
     83 20:09:42.5 192.168.81.220        158.110.30.62         TCP      60     4295 > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     84 20:09:42.5 192.168.81.220        158.110.30.62         TCP      60     4294 > msg-icp [RST] Seq=54 Win=32 Len=0
     85 20:09:42.6 192.168.81.220        158.110.30.62         TCP      60     4295 > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
     86 20:09:42.6 192.168.81.220        158.110.30.62         TCP      106    4295 > msg-icp [PSH, ACK] Seq=1 Ack=1 Win=32 Len=52
     87 20:09:42.6 192.168.81.220        158.110.30.62         TCP      60     4295 > msg-icp [FIN, ACK] Seq=53 Ack=2 Win=32 Len=0
     88 20:09:42.6 192.168.81.220        158.110.30.62         TCP      60     4295 > msg-icp [RST] Seq=54 Win=32 Len=0
     89 20:09:42.6 192.168.81.220        158.110.30.62         TCP      60     4296 > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     90 20:09:42.6 192.168.81.220        158.110.30.62         TCP      60     4296 > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
     91 20:09:42.7 192.168.81.220        158.110.30.62         TCP      106    4296 > msg-icp [PSH, ACK] Seq=1 Ack=1 Win=32 Len=52
     92 20:09:42.7 192.168.81.220        158.110.30.62         TCP      60     4296 > msg-icp [FIN, ACK] Seq=53 Ack=2 Win=32 Len=0
     93 20:09:42.7 192.168.81.220        158.110.30.62         TCP      60     4296 > msg-icp [RST] Seq=54 Win=32 Len=0
     94 20:09:42.7 192.168.81.220        158.110.30.62         TCP      60     4297 > msg-icp [SYN] Seq=0 Win=32 Len=0 MSS=576
     95 20:09:42.7 192.168.81.220        158.110.30.62         TCP      60     4297 > msg-icp [ACK] Seq=1 Ack=1 Win=32 Len=0
(e continua così con la stessa sequenza che si ripete: secondo il server TCP di Gambas, neanche ricevo la comunicazione)

[pastrank]

Magari voi ci capite qualcosa.

Io , ma ti ripeto la storia per cui le porte sotto 1024 non possono essere usate con Linux nei processi utente. A parte che a questo punto, pur rileggendo il thread, non capisco piu' quello che dicevi di dover fare... dunque, volevi comunicare con dei dispositivi, esterni alla tua lan e quindi su internet, che sono i client, dotati di firmware non modificabile perche' se no modificheresti la porta, e devono comunicare con il server che sta sul tuo pc.
Quindi, dal router, le richieste sulla porta 29 che giungono dall'esterno devono essere nattate e indirizzate verso l'ip del pc dove hai il server, con una procedura analoga a quella che si fa con i programmi di file sharing. Per il server, hai quindi piu' alternative: o continui ad usare la 29, eseguendolo come root, o puoi creare una regola con iptables che trasli la porta 29 in 2xxxx e usarlo cosi', piu' sicuramente varie che non mi sovvengono.

[pastrank]

le richieste sulla porta 29

A proposito, leggo che la porta 29 potrebbe essere impegnata...
http://www.debianhelp.co.uk/ports.htm

[El Berto]

Eh, fare il NAT è un po' un casino.....
Mi sa che mi tocca aspettare di avere il nuovo hardware con il firmware che usa la porta 2000.

Mi è venuta in mente un'altra cosa, non so se sono O.T.:
il client si collega al server, e visto che ha un buffer limitato, per trasmettere dati lo fa a più riprese (trasmette il client, risponde il server, trasmette nuovamente il client, risponde nuovamente il server.....).
Nella finestra di dialogo (ho preso l'esempio ServerSocket) ho "Socket number x..." e poi c'è lo scambio di dati.
Dovrei prevedere che il server si pianta, quindi il client dovrebbe avere un timeout che se il server non risponde entro un certo tempo, chiude la connessione.
Ma devo anche fare l'opposto: se è il client a piantarsi, devo chiudere il socket del server.
Uso un timer che azzero ognivolta (nella sub Socket_Read) che mi arrivano dei dati.
Quando mi scatta il timer, cioè il timeout, mi basta chiamare "Socket_Closed"?

[pastrank]

Eh, fare il NAT è un po' un casino.....
Mi sa che mi tocca aspettare di avere il nuovo hardware con il firmware che usa la porta 2000.

Avere le porte necessarie visibili dall'esterno tramite nat - o come lo chiama il tuo router - dovrebbe essere condizione necessaria per gestire un server... per esempio, il web server lighttpd, che ho su questo pc, senza nat, non e' raggiungibile dall'esterno. Farlo e' semplicissimo, ammesso di non avere un router blindato o essere nattati in una rete tipo Fastweb, puoi vedere gli esempi su www.portforward.com.

Quando mi scatta il timer, cioè il timeout, mi basta chiamare "Socket_Closed"?

Con i socket mi sono limitato a fare qualche prova, meglio lo dica qualcuno piu' esperto di me qual'e' la procedura corretta :-)

[El Berto]

Ho un server TCP che accetta connessioni da client remoti; ad un certo punto voglio terminare la connessione, quindi vorrei che il server "sbattesse" fuori alcuni client.
Per fare una prova ho deciso di chiudere TUTTE le connessioni, quindi faccio Client.Close(0) finchè non mi dice che Client è vuoto.
Ora, con il comando

Codice: [Seleziona]

netstat -anp --tcp

mi ritrovo che lo stato della connessione è "FIN_WAIT1" anche dopo che ho chiuso tutti i socket.
Sapreste spiegarmi come mai?