Socket drops out between desktop and Emulator

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am trying to connect a simple desktop C# Form app to another simple NetCF
C# Form app running under the Emulator using sockets.

The symptom is that after a few String writes from the desktop to the
Emulator the socket drops out with an error of "Unable to read data from the
transport connection." and an internal error of "A blocking operation was
interrupted by a call to WSACancelBlockingCall".

The desktop code is as follows--
IPAddress localAddr = IPAddress.Parse("192.168.1.101");
listener = new TcpListener(localAddr, 1234);
listener.Start();
socket = listener.AcceptSocket();
stream = new NetworkStream(socket);
writer = new BinaryWriter(stream);
this.Th1b=new Thread(new ThreadStart(this.ThSt1b));
Th1b.Name="Th1b";
Th1b.Start();

//desktop thread function for Th1b as follows, choice of TimeIntervalJ1
from 30ms to 7s does not effect the problem

public void ThSt1b()
{
String Error,Str="ThSt1b";
while(ThreadRun1)
{
try
{writer.Write(Str);
Debug.WriteLine("ThSt1b wrote: "+Str);
}
catch(Exception e)
{
Error=e.Message;
return;
}
Thread.Sleep(TimeIntervalJ1);
}
}

The Emulator side is as follows--
//start a thread to handle messages after the connection is made
IPAddress localAddr = IPAddress.Parse("192.168.1.101");
TcpClient client = new TcpClient();
client.Connect(localAddr, 1234);
Stream stream = client.GetStream();
reader = new BinaryReader(stream);
this.Th1a=new Thread(new ThreadStart(this.ThSt1a));
Th1a.Start();

//thread code
public void ThSt1a()
{
String Str="ThSt1a",Error;
while(this.ThreadRun1)
{
try
{Str=reader.ReadString();
TraceEx.WriteLine("ThSt1a read: "+Str);
}
catch(Exception e)
{Error=e.Message;
TraceEx.WriteLine("ThSt1a error: "+Error);
return;
}
}
}

Any help would be appreciated.

Thanks.
 
I just verified that the exact same code does work between two desktop App's.
Something specific to Netcf or the Emulator?

Again any help would be appreciated.
 
What about with a real device? Remember that you've got a lot more crap
going on with the emulator and the desktop than between two full-fledged
devices, each with their own IP, adapter, etc.

You also haven't told us which emulator it is, which version of VS.NET, etc.

Paul T.
 
Vs2003 is the Ide. Using .NET 1.1 and Netcf 1.0 (v1.0.5000).

I did try it on an actual device that uses a sh4 processor. It gave the same
symptom.

Again, appreciate any suggestions.

--
John Olbert
(e-mail address removed)



Paul G. Tobey said:
What about with a real device? Remember that you've got a lot more crap
going on with the emulator and the desktop than between two full-fledged
devices, each with their own IP, adapter, etc.

You also haven't told us which emulator it is, which version of VS.NET, etc.

Paul T.
Click to expand...
 
And it's the desktop end that drops out and gives that error, right? It
sounds to me as though something is wrong with either the desktop machine
itself (it's a wireless connection and it's losing contact with the access
point), or your program, causing the socket to be closed out from under your
thread. Generally, this doesn't happen, so it's something that you're doing
there.

Paul T.
 
I found by expermentation that by placing a slight delay "Thread.Sleep(20);"
as the top line of the while statement at the WinCe end allowed the
connection to be maintained without error. This may in effect solve the
problem since 20ms is not a serious problem but it still leaves open as to
why. The code is simple and straightforward though that does not make it
correct.

Any ideas as to why a slight delay on the WinCe end (this solution works
with both Emulator and an actual device) should allow the channel to stay
open?

Thanks.
 
This is my second reply. I realized I didn't answer your first question. No,
it is the WinCe end that drops out first.

Thanks.
 
So, WinCE errors out when it tries to call reader.ReadString()? At a guess,
I'd say that the difference is that, in the Sleep case, there's always a
string there to be read; in the no-Sleep case, there's *not*. Are you not
handling the case where there is no string for the reader to read? Does it
throw an exception in that case?

Paul T.
 
I am letting the reader.ReadString() block in its own worker thread until a
message comes in. Is that a problem?

Thanks.
 
It looks to me like a BinaryReader will generate an exception when the end
of the stream is reached and I think that's what is going to happen if you
try to read before the next string has been dumpted into the pipe by the
writer.

Paul T.
 
Back
Top