[vb.net 2005 e TCP] problema di memoria

[Kahm]

salve a tutti
avendo un programma, che lo avvio come finestra DOS e lui rimane in attesa di una chiamata TCP
il problema è che dopo varie chiamate, la RAM aumenta di continuo,e non riesco a determinare dove è il pezzo di codice che da il problema

faccio presente che le altre routine SUB che vengono chiamate sono totalmente escluse da bug in quanto le hoi usate per molto tempo in altri programmi,ovviamente penso che il problema sia qui in quanto è la prima volta che mi cimento in TCP

questo è il codice

    Public Sub Main()
        Dim TcpThread As Thread
        Try
            'Starting the TCP Listener thread.
            TcpThread = New Thread(AddressOf StartListen)
            TcpThread.Start()
        Catch ex As Exception
            Throw New Exception(ex.Message)
            Console.WriteLine("Si è verificato un errore")
            TcpThread.Abort()
        End Try
    End Sub

    Public Sub StartListen()
        ' Must listen on correct port- must be same as port client wants to connect on.
        Const portNumber As Integer = 8000
        Dim tcpListener As New TcpListener(portNumber)
        Dim clientData As String

        Try
            While (True)
                tcpListener.Start()
                Console.WriteLine("In attesa di una nuova richiesta...")
                Dim tcpClient As TcpClient = tcpListener.AcceptTcpClient()
                Console.WriteLine("Richiesta ricevuta.")

                Dim networkStream As NetworkStream = tcpClient.GetStream()

                Dim bytesToRead(tcpClient.ReceiveBufferSize) As Byte
                Dim numBytesRead As Integer = networkStream.Read(bytesToRead, 0, CInt(tcpClient.ReceiveBufferSize))

                clientData = Encoding.ASCII.GetString(bytesToRead, 0, numBytesRead)

                Dim tipoOperazione As String = Left(clientData, 3)
                Dim responseString As String

                Select Case tipoOperazione
                   
                    Case Is = "TUFF"
                        Console.WriteLine("operazione ripristino")
                        Call verifica(clientr)
                        responseString = Trasmissione & "?"
                End Select

                Dim sendBytes As [Byte]() = Encoding.ASCII.GetBytes(responseString, 0, responseString.Length)
                networkStream.Write(sendBytes, 0, sendBytes.Length)
                tcpClient.Close()
                tcpListener.Stop()
            End While

        Catch ex As Exception
            Console.WriteLine(ex.Message)
            tcpListener.Stop()
        End Try
    End Sub

posto anche il codice che spedisce la stringa alla porta,forse si tratta qui del problema

  Private Function SendDataBarcode(ByVal BarCode As String) As Boolean
        Dim tcpClient As New TcpClient()
        Try
            tcpClient.Connect(Server, 8000)
            Dim networkStream As NetworkStream = tcpClient.GetStream()

              Dim sendBytes As [Byte]() = Encoding.ASCII.GetBytes("BAR@" & BarCode & "@" & Server)
            networkStream.Write(sendBytes, 0, sendBytes.Length)
            ' Read the NetworkStream into a byte buffer.
            Dim bytes(tcpClient.ReceiveBufferSize) As Byte
            Dim numBytesRead As Integer = networkStream.Read(bytes, 0, CInt(tcpClient.ReceiveBufferSize))
            Dim returndata As String = Encoding.ASCII.GetString(bytes, 0, numBytesRead)
            Dim datiServer() = Split(returndata, "@")

            'Controllo il barcode.
            If datiServer(0) <> "failed" Then
                txtArticolo.Text = datiServer(6)
                txtMarchio.Text = datiServer(1)
                Return True
            Else
                Return False
            End If

        Catch ex As Exception
            Return False
        Finally
            tcpClient.Close()
        End Try
    End Function

[Alethesnake]

ciao,
premetto che ho guardato solo la parte del tuo codice che riguarda il listener, il client no.
Senza scendere nel merito di come vengono processate le richieste di un nuovo client, ho notato due errori di fondo:

fai lo start e lo stop del listener all'interno del ciclo e non ha senso, anche perché così se si connettono due client contemporaneamente il primo che esce butta fuori anche l'altro.
start va prima e stop ovviamente dopo il ciclo.

nel ciclo infinito che usi per accogliere nuovi client non vedo un modo per uscire, ciò significa che per interrompere l'ascolto devi far crashare l'applicazione altrimenti il thread resta attivo e il processo non muore.

il costruttore TcpListener che accetta in ingresso solo la porta è obsoleto (vedi documentazione msdn), meglio usare quello che accetta in ingresso anche l'ipAddress.

[Kahm]

Originariamente inviato da Alethesnake
ciao,
premetto che ho guardato solo la parte del tuo codice che riguarda il listener, il client no.
Senza scendere nel merito di come vengono processate le richieste di un nuovo client, ho notato due errori di fondo:

grazie,molto interessanti i tuoi suggerimenti, mi stai schiarendo moltissimo le idee in merito, permettimi dunque di schiarirmi le idee in merito

fai lo start e lo stop del listener all'interno del ciclo e non ha senso, anche perché così se si connettono due client contemporaneamente il primo che esce butta fuori anche l'altro.
start va prima e stop ovviamente dopo il ciclo.

ok si ,
mi suggerisci di fare uno START quindi ciclo e solo dopo che premo per uscire faccio lo STOP
giusto?

nel ciclo infinito che usi per accogliere nuovi client non vedo un modo per uscire, ciò significa che per interrompere l'ascolto devi far crashare l'applicazione altrimenti il thread resta attivo e il processo non muore.

ops, è vero!, attualmente è una finestra DOS,quindi poco malleabile a keydon e niente pulsanti, ma penso di poter rimediare mettendo un pulsante in una windows form,sempre semi confermi lo stop suggerito sopra

il costruttore TcpListener che accetta in ingresso solo la porta è obsoleto (vedi documentazione msdn), meglio usare quello che accetta in ingresso anche l'ipAddress.

interessante, :master:
mi documenterò a riguardo

[Alethesnake]

il ciclo infinito nel listener serve a mantenere "vivo" il listener stesso in modo da poter essere disponibile per i client che si connettono mentre è attivo.
lo start va prima e lo stop dopo.

riguardo il prevedere una via d'uscita questa deve esserci in ogni caso, sia con console application che con windows application e il perché è semplice: il thread va "spento" quando chiudi l'applicazione. finché lavori in debug mode forse il problema non si pone perché gestisci l'applicazione da visual studio, ma alla release il thread ti resterebbe comunque aperto.

generalmente si setta una variabile di classe bool che viene impostata a true prima di effettuare lo start, e messa a false dall'esterno quando vuoi fermarlo (richiamando anche lo stop del trhead col quale lanci il listener.
qualcosa tipo (perdonami il c# ma mi è più familiare, tanto si capisce lo stesso)

private bool listenerStatus;
...

//di questo puoi farne anche a meno avendo il metodo StopListener
public bool ListenerStatus
{
    set {this.listenerStatus = value; }
}

public void StartListener()
{
    this.ilTuoThread = new Thread(this.StartListen);
    this.ilTuoThread.Start();
}

private void StartListen()
{
    this.listenerStatus = true;

    this.ilTuoListener.Start();

    while(this.listenerStatus)
    {
        TcpClient tcpClient = this.ilTuoListener.AcceptTcpClient();
        
        //fai quello che ti serve
    }
    
    if(this.ilTuoListener.Active)
        this.ilTuoListener.Stop();
}

public void StopListener()
{
    this.listenerStatus = false;

    this.ilTuoListener.Stop();

    this.ilTuoThread.Abort();
}

[Kahm]

grazie
sono gia all'opera di studio

cosi' per pura curiosita', visto che hai piu' esperienza di me

non chiudendo il listener(da come mi hai fatto notare) questo comportava un problema di comunicazione nelle successive chiamate a quella porta?

[Alethesnake]

nel tuo ciclo il listener veniva comunque stoppato, ma ad ogni cliente che si connetteva..

se il listener non viene buttato giù la porta resta impegnata e non riesci a riconnetterti sulla medesima