Looking for VB.NET Help with TCP Communications

[Bob Schroeck]

Is anyone on the board familiar enough with .NET-based network communications to help me with a problem?  I've got a situation where I'm sending a string to a program on a different computer using a TCPClient, with a TCPListener active and waiting for a response.  The response should be all but instantaneous, and when detected would spawn a new TCPClient to accept the connection and receive the response, but instead I'm timing out.  I can see that my message to the remote computer is being received and acted upon, and the return message is being generated (and logged).  I can't change the remote program, as it's a standard configuration for multiple products.  And the code I'm using is allegedly the standard implementation for the other side of the connection.  But regardless of whether I leave the code as it was already written, or attempt to tweak it, I see no evidence that anything's coming back across the network at me.

Ideas, suggestions, brickbats?

Thanks.
-- Bob
---------
Then the horns kicked in...
...and my shoes began to squeak.

[CattyNebulart]

use wireshark on you end, check the outgoing data and incoming data. If you don't get incoming data that's where the problem, lies and use wireshark on the remote end to check the outgoing data. From the symptoms described my initial suspicion is a firewall somewhere blocking the transmission back.

Also some of the stream setup for TCP can be a bit wonky and block until it gets the data it needs, so check that the code doesn't stop before you expect it to, waiting for remote input (It is unlikely from what you describe, but past experience tells me this is the most common problem)
E: "Did they... did they just endorse the combination of the JSDF and US Army by showing them as two lesbian lolicons moving in together and holding hands and talking about how 'intimate' they were?"
B: "Have you forgotten so soon? They're phasing out Don't Ask, Don't Tell."

[Bob Schroeck]

I forgot to post my thanks last week, Catty. Your advice hasn't exactly solved my problem, but it has narrowed the cause down considerably.
-- Bob
---------
Then the horns kicked in...
...and my shoes began to squeak.

[CattyNebulart]

You are welcome. I did work as a pseudo TA in my networking class as I was the only one to have done it before so I have seen a lot of different failure modes.

If you post more details I can post a more detailed analysis. But I am unsure about how much you can/should share about your work in a public forum.
E: "Did they... did they just endorse the combination of the JSDF and US Army by showing them as two lesbian lolicons moving in together and holding hands and talking about how 'intimate' they were?"
B: "Have you forgotten so soon? They're phasing out Don't Ask, Don't Tell."

[Bob Schroeck]

Oh, it's real simple. I have a TCPListener open on port 3336, waiting for an incoming signal from a remote program. Wireshark shows that the remote program is,right on cue, sending the SYNs to 3336 to initiate a session -- three, one initial attempt and two retries -- but for some reason, my program is not seeing them. I'm pretty sure the Windows firewall isn't blocking the connection (not 100%, as it's damned hard to understand the nest of rules), but beyond that I'm drawing a blank.
-- Bob
---------
Then the horns kicked in...
...and my shoes began to squeak.

[CattyNebulart]

I'm assuming that you have something like "Socket socket = tcpListener.AcceptSocket()" to have a synchronous wait? put a println directly after that to see if it gets there (probably not) and a println immediately before to see if it starts listeneing. Wireshark or other tools should be able to list which program is listening to which socket, so check that something is indeed listening on 3336.

If something is indeed listening (and I suspect it isn't) then try enabling network tracing; http://msdn.microsoft.com...us/library/a6sbz1dx.aspx
E: "Did they... did they just endorse the combination of the JSDF and US Army by showing them as two lesbian lolicons moving in together and holding hands and talking about how 'intimate' they were?"
B: "Have you forgotten so soon? They're phasing out Don't Ask, Don't Tell."

[Bob Schroeck]

Oh yeah, all that was already in place -- I should have mentioned that I am maintaining/expanding someone else's code, and this is in a library function that was working in a lot of other applications.

I have fixed the problem, by the way, in no small part due to your help -- the recommendation of Wireshark alone saved me many hours of fruitless and frustrated staring at the screen. As it turned out, the culprit was the firewall. Turning it off entirely cleared up the problem, so I went in and deleted what turned out to be several contradictory rules concerning the program I am working on, reactivated it, and then let it set it self properly the first time I ran the app afterwards.

I am ze happy.

Thanks again for the advice -- rest assured I am printing it out and storing it in my collection of advice and references.
-- Bob
---------
Then the horns kicked in...
...and my shoes began to squeak.