TCP client lnet , leggere la porta locale

[lorenzofesta]

ciao a tutti , lnet funziona davvero bene ma ...
ho qualche piccola difficolta' con un particolare ,  Usando il componente visuale TCP ( TLTCPComponent ) come client , se si interroga la propieta'  socket.localport viene restituita la porta remota , anche facendo tcp.iterreset e interrogando tcp.iterator.localport si ottiene lo stesso risultato ,
la porta locale invece e' diversa e si incrementa di uno per ogni connessione , verificato con wireshark ;
Probabilmente mi perdo io in un bicchiere d'acqua ,
qualcuno ha avuto necessita' di conoscere la porta locale ?
e se si come ha risolto ?

altra cosa , in teoria dalla documentazione il componente TCP usato come client ha un solo socket , in effetti utilizzando iterreset e iternext sembra cosi' ,
pero' sempre verificando con wireshark sembra che se si fa connect senza prima disconnettersi le connessioni precedenti restino attive, ed in effetti sembra anche che ricevano , a questo punto e' lecito usarlo in questo modo per ottenere connessioni multiple con un solo componente TCP ?  ( potendo leggere la localport si potrebbero anche distinguere nell'evento receive )

dimenticavo sto usando windows xp

[nomorelogic]

ciao a tutti , lnet funziona davvero bene ma ...
ho qualche piccola difficolta' con un particolare ,  Usando il componente visuale TCP ( TLTCPComponent ) come client , se si interroga la propieta'  socket.localport viene restituita la porta remota , anche facendo tcp.iterreset e interrogando tcp.iterator.localport si ottiene lo stesso risultato ,
la porta locale invece e' diversa e si incrementa di uno per ogni connessione , verificato con wireshark ;
Probabilmente mi perdo io in un bicchiere d'acqua ,
qualcuno ha avuto necessita' di conoscere la porta locale ?
e se si come ha risolto ?

è tutto normale, la porta in uscita (quella che tu intendi come locale, quella del client insomma) è gestita dal sistema operativo e non mi risulta che sia possibile impostarla. è scelta "casualmente"  e serve per gestire il flusso di dati tra il client e il server una volta che è stata stabilita la connessione.

altra cosa , in teoria dalla documentazione il componente TCP usato come client ha un solo socket , in effetti utilizzando iterreset e iternext sembra cosi' ,
pero' sempre verificando con wireshark sembra che se si fa connect senza prima disconnettersi le connessioni precedenti restino attive, ed in effetti sembra anche che ricevano , a questo punto e' lecito usarlo in questo modo per ottenere connessioni multiple con un solo componente TCP ?  ( potendo leggere la localport si potrebbero anche distinguere nell'evento receive )

anche qua tutto normale, il multithreading (relativavente alle N connessioni in ingresso) lo deve gestire il server e non il client.
se fai un connect prima di aver disconnesso la connessione precedente non liberi le risorse né sul client né sul server (ma quest'ultimo dopo un timeout libererà comunque la connessione inutilizzata).
è per questo che wireshark rileva le porte locali (quelle del client) delle precedenti connessioni come ancora attive: il server non sa (visto che non hai fatto la disconnessione) che tu hai allegramente "perso" il socket precedente e continua a spedire i dati che nessuno leggerà.

non mi è mai capitato di dover lanciare più connessioni da uno stesso client contemporaneamente verso lo stesso server. credo tu debba istanziare più componenti, uno per connessione che intendi stabilire.

l'importante è che poi ad ogni "connect" segua un "disconnect".

[lorenzofesta]

Grazie
Pero' rimango perplesso , va bene che non si possa impostare la porta locale,
pero' almeno leggerla sarebbe utile ,

le connessioni che restano aperte in realta' ricevono , anche se non riesco a distinguere chi e' che le riceve
e non so se e' un funzionamento normale o causale ,

quello che volevo sperimentare e' una specie di proxy per una applicazione che apre tante connessioni
sulla stessa porta verso lo stesso server e mi serviva un modo per poter mandare le risposte indietro alla porta giusta
senza dover entrare nel merito del contenuto del pacchetto , l'idea era di mandare avanti la richiesta aprendo un socket con la stessa porta locale ... cosi' che la risposta che gli arriva vada poi mandata su quella stessa porta , ma per fare cosi' serve di poter specificare la porta locale mi sa che desisto

[nomorelogic]

se non ho capito male vuoi fare qualcosa tipo quello che fa un browser web.
se apri un qualsiasi browser infatti e lanci N richieste dello stesso url (= stesso server remoto sulla stessa porta 80) puoi notare con wireshark che i socket aperti sono diversi.
ovviamente ogni socket comunicherà su una porta locale (quelle scelte casualmente dal sistema opertivo) diversa.

il problema è che se usi un componente tcp client che ti permette di gestire un unico socket alla volta, tutto quello che potrai fare è istanziare n componenti client.

sicuramente la porta locale è raggiungibile ma visto che è pressoché inutile utilizzarla (almeno nelle intenzioni di chi ha realizzato il client tcp) secondo me la troverai al massimo come proprietà privata.

studia i sorgenti del tcp client, per fare quello che vuoi devi quantomeno usare delle chiamate alle api di sistema. ma in questo campo non so esserti utile


Edit:
prima di passare alle api come ho detto sopra, dai un'occhiata a synapse; è una libreria molto valida e multipiattaforma, basata sui blocking sockets. questo vuol dire che dovrai lavorare con i thread ma potrebbe essere un buon punto di partenza.