[.net] TCPclient werkt niet release build wel in debug build

[Koen_R]

Ik schrijf momenteel een client (in .net) die over een TCP connectie een aantal plain text commando's (van max 255 bytes) moet versturen naar een oude server applicatie.

Ik gebruik daarvoor deze code (versimpeld):

code:

string message = "message";
string response = "";

TcpClient client = new TcpClient();
client.Connect(IPAddress, Port);

NetworkStream stream = client.GetStream;

if (stream.CanRead && stream.CanWrite) {
    byte[] sendBytes = Encoding.ASCII.GetBytes(message);
    stream.Write(sendBytes, 0, sendBytes.Length);

    byte[] receiveBytes = new byte[client.ReceiveBufferSize + 1];
    stream.Read(receiveBytes, 0, client.ReceiveBufferSize);
    response = Encoding.ASCII.GetString(receiveBytes);

}

Tijdens debuggen werkt dit perfect, maar zodra de applicatie gecompileerd is dan blijft hij hangen op 'stream.Read'. m.a.w. hij lijkt geen data terug te geven. Als ik een timeout van een seconde of 10 op geef, dan krijg ik de volgende exception:

code:

System.IO.IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

Verder stoeien met timeouts en dergelijke mocht niet baten; belangrijkste vraag is: waarom werkt hij wel perfect in Debug mode, maar niet meer zodra hij gecompileerd is.

[Sebazzz]

Klopt regel 9?

C#:

if (stream.CanRead & stream.CanWrite) {

Dat je niet "&&" maar "&" gebruikt.

[Koen_R]

Sebazzz schreef op woensdag 23 maart 2011 @ 14:49:
Dat je niet "&&" maar "&" gebruikt.

Goed gezien... was een typefoutje en aangepast in post...

[Flard]

Heb je je firewall gecontroleerd?

Debugapplicaties draaien onder een vhost.exe die je misschien al eens eerder in je firewall heb toegestaan, terwijl de release build (z'n eigen .exe) nog niet toegestaan is?

[Koen_R]

Nope, leek een logische mogelijkheid, maar aan- uitzetten firewall maakt niets uit.

[Verwijderd]

En als je na de write een flush doet?

Edit: zie je aan de server kant wel een correcte verwerking? (Komt je bericht aan en wordt er een response gestuurd)

[ Voor 61% gewijzigd door Verwijderd op 23-03-2011 16:19 ]

[Koen_R]

Nog wat verder getest; en sommige commando's doen het wel goed zowel compiled als debug.

Je moet je een commando overigens voorstellen als zoiets:

code:

6300020110323    161322          |AO00|AA20550491111110|AC|AD

Bij een specifiek commando werkt het dus alleen in Debug mode, niet gecompiled. Dan kan ik wel een commando sturen, maar blijft hij hangen op de stream.read. Andere commando's doen het wel, en krijg ik ook direct een response terug.

Het wordt wat mij betreft steeds vreemder... Helaas kan ik aan de serverkant niets doen, het is een oude applicatie op afstand waar ik verder geen invloed op heb.

Verwijderd schreef op woensdag 23 maart 2011 @ 16:16:
En als je na de write een flush doet?

Edit: zie je aan de server kant wel een correcte verwerking? (Komt je bericht aan en wordt er een response gestuurd)

Flush heeft geen effect op NetworkStreams.

The Flush method implements the Stream.Flush method; however, because NetworkStream is not buffered, it has no affect on network streams (MSDN)

[Woy]

Het probleem lijkt me toch aan de serverkant te zitten dan. Misschien iets met timing. Probeer eens met iets als Wireshark te kijken wat er precies op TCP/IP nivo gebeurt?

[Koen_R]

Ik ben niet heel bekend met Wireshark, maar de pakketinhoud/lengte van de 2 sessie (debug vs compiled) lijkt gelijk te zijn.



Ik heb van beide sessies het eerste commando gehighlight, degene waar het dus in de 2e sessie fout gaat.
Je ziet dat een pakket verstuurd wordt met lengte=23 vanaf mijn intern IP (192.168..) naar de server (IP 193.173..). In de gedebugde sessie krijg ik twee pakketten terug. Het 2e pakket met lengte=14 bevat de response die ik verwacht.

In de gecompilede sessie krijg ik het pakket pas terug nadat ik 5 sec. later nogmaals het zelfde command stuur (je ziet ook 2 pakketten van lengte=23).

Het zal niet aan een of andere gekke compile switch liggen toch? Ik gebruik gewoon standaard instellingen.
Anders ga ik toch maar eens kijken of ik de server met een nog ouder protocol (namelijk telnet...) betrouwbaarder kan aansturen.