Socket reuse problem

  • Thread starter Thread starter Me
  • Start date Start date
M

Me

Argg.. another one of those CF vs normal framework things.

What I have is a program that creates a lot of socket connections over a
very short period of time (maybe a few hundread connections over a 2-3
minute period). What I am seeing is that it starts to slow way down in
terms of the Socket() constructor being called which I am thinking has to do
with the PDA running out of usable ports or something similar.

What I am using is BeginConnect() to establish my connection and if it takes
more then 1-2 seconds then I issue a Close() on the socket to abort it.

I have tried using multiple threads (one for each connection I will be
making) but I ended up running intoa OutOfMemory exception - even though I
tried calling the GC manually to free up old stuff.

Now what I have is just a single threaded class that has an ArrayList of
several classes that contain a Socket and other info in it. I use a timer
(100-1000ms interval) to loop through all the connections and check to see
if they are connected, timed out, etc. and then process the packets that are
recd. Right now I am only performing a connection attempt and then closing -
there is no send/recv implemented yet.

I hope this is enough of an overview to give you an idea of what I am doing.
I have tried using SetSocketOption() but it is hard to figure out what
is/not actually supported (aka actually works) in the CF. I have tried the
no linger option but it didnt help.

Any thoughts?

Anyone able to constantly open/close socket connections without any
probelms? I know on a PC I would expect to run out of ports (if they are
lingering around) after a few thousand but I am seeing problems on the PDA
after only a few hundread.

Thanks!
Chuck
 
That's likely to be a memory problem. Each socket needs data buffers, etc.
and, on top of the memory overhead of the .NET CF itself, you're adding tons
of extra buffers (at the unmanaged code level), as well as the overhead of
creating a bunch of new objects in the managed code.

Your memory overhead will likely be lower with native code. That's
something relatively easy to test so my first suggestion would be to write
the socket parts of your code in native C/C++ and see what happens. If the
OS/WinSock is responsible for the slowdown, your only option is going to be
finding a better way to do this (or one that uses fewer resources at each
moment). If the native code works fine, you might be able to use a native
DLL and P/Invoke to it from your managed code UI application to do the
socket stuff.

Paul T.
 
Back
Top