Windows Mobile 5.0, .NETCFv2.0, and many sockets

  • Thread starter Thread starter stu
  • Start date Start date
S

stu

I am looking for a good way to handle numerous sockets (1 UDP and as
many as 20+ TCP child sockets) in WM 5.0 using C# and the .NETCFv2.
Currently, I'm using async class and it works fine for small numbers of
sockets; 1 UDP and up to 15 or so TCP child sockets. When I get to
more than 15 (or so) I have an issue with other threads, using the
threadpool, not running. Specifically, I have a managing thread (using
the System.Threading.Timer stuff) that ceases to be called once the
number of async calls gets rather high. Do the async socket calls
block the threadpool threads? If so, is there a way to get around
this, or the is the best idea just not to use async socket calls in
this situation? I can't find any good documentation on how things are
handled within the OS (a pointer to such documentation would be
_greatly_ appreciated, too). I was at MEDC in Vegas last week, but
failed to catch one of the VM Core developers to bug them about this.
From looking at other posts, it seems that Socket.Select() is a much
Click to expand...
better method for handling a large number of sockets. When using
select() is there a way to add another event that I can raise to get
select() to come back or will it only respond to socket events? For
example, I want to add another socket to the read array. I know in the
old-school select() you could use generic events in the select array.

Many thanks!!!

stu =)
 
It's just my own preference, but I dislike asynch sockets for situations
like this. Yes, you can use a single dispatch thread that continuously runs
and checks every open socket for activity that needs a response. In my own
code, I'd be much more likely when using threading, to use blocking sockets,
allowing a thread on which there is no corresponding socket activity to
sleep, freeing up those processor cycles for threads/sockets which *are*
active. I think that this balances the load better. Since you're on a very
resource-constrained device, you'll have to test to see what works best.

Paul T.
 
Yes, I agree async sockets were the poor choice for this. From my
knowledge, using async sockets is encouraged in big .NET (this is what
I've read, I don't have any experience in designing larger apps), so I
figured the same was true for the .netcf.

As for the single thread approach, are you talking about using
socket.select() for all sockets or using socket.poll() on each
individual socket and looping through the list (over and over and
over)?

As for the full thread approach, my fear is just eating up a lot of
resources. Is it detrimental to have upwards of 20 receive() threads
running around?

Please let me know about the single thread approach (it is more out of
curiousity at this point).

Thanks!

stu =)
 
Well, the scheduler has to schedule all of those threads, but, unless you're
constantly receiving packets on all of the sockets, this will be more
conservative of CPU cycles than polling and, when everything is idle, you're
using *zero* CPU cycles because all of the threads will be blocked waiting
for data to arrive.

Yes, when I say a single thread, I mean something that iterates over a list
of open sockets, calling select() for each one in turn and then doing
something when a given socket has data ready to be received (or whatever).

Paul T.
 
With select() and a single thread you can block on all sockets at once
until one of them gets something; select can listen to a whole list.
Do you think that multiple threads is still more effecient that this?
(As I said this is more of a curiosity, at this point.) Thanks for
your input!

stu =)
 
I'm not sure that either is "more efficient" in either case (more efficient
at what?). It's much easier to read a multi-threaded application, because
each thread is the "same" as all the others and is relatively simple,
there's no big loop running everything. It may be harder to debug, but I'll
live with that.

Paul T.

stu said:
With select() and a single thread you can block on all sockets at once
until one of them gets something; select can listen to a whole list.
Do you think that multiple threads is still more effecient that this?
(As I said this is more of a curiosity, at this point.) Thanks for
your input!

stu =)

Well, the scheduler has to schedule all of those threads, but, unless
you're
constantly receiving packets on all of the sockets, this will be more
conservative of CPU cycles than polling and, when everything is idle,
you're
using *zero* CPU cycles because all of the threads will be blocked
waiting
for data to arrive.

Yes, when I say a single thread, I mean something that iterates over a
list
of open sockets, calling select() for each one in turn and then doing
something when a given socket has data ready to be received (or
whatever).

Paul T.

stu said:
Yes, I agree async sockets were the poor choice for this. From my
knowledge, using async sockets is encouraged in big .NET (this is what
I've read, I don't have any experience in designing larger apps), so I
figured the same was true for the .netcf.

As for the single thread approach, are you talking about using
socket.select() for all sockets or using socket.poll() on each
individual socket and looping through the list (over and over and
over)?

As for the full thread approach, my fear is just eating up a lot of
resources. Is it detrimental to have upwards of 20 receive() threads
running around?

Please let me know about the single thread approach (it is more out of
curiousity at this point).

Thanks!

stu =)

Paul G. Tobey [eMVP] wrote:
It's just my own preference, but I dislike asynch sockets for
situations
like this. Yes, you can use a single dispatch thread that
continuously
runs
and checks every open socket for activity that needs a response. In
my
own
code, I'd be much more likely when using threading, to use blocking
sockets,
allowing a thread on which there is no corresponding socket activity
to
sleep, freeing up those processor cycles for threads/sockets which
*are*
active. I think that this balances the load better. Since you're on
a
very
resource-constrained device, you'll have to test to see what works
best.

Paul T.

I am looking for a good way to handle numerous sockets (1 UDP and as
many as 20+ TCP child sockets) in WM 5.0 using C# and the .NETCFv2.
Currently, I'm using async class and it works fine for small numbers
of
sockets; 1 UDP and up to 15 or so TCP child sockets. When I get to
more than 15 (or so) I have an issue with other threads, using the
threadpool, not running. Specifically, I have a managing thread
(using
the System.Threading.Timer stuff) that ceases to be called once the
number of async calls gets rather high. Do the async socket calls
block the threadpool threads? If so, is there a way to get around
this, or the is the best idea just not to use async socket calls in
this situation? I can't find any good documentation on how things
are
handled within the OS (a pointer to such documentation would be
_greatly_ appreciated, too). I was at MEDC in Vegas last week, but
failed to catch one of the VM Core developers to bug them about
this.

From looking at other posts, it seems that Socket.Select() is a much
better method for handling a large number of sockets. When using
select() is there a way to add another event that I can raise to get
select() to come back or will it only respond to socket events? For
example, I want to add another socket to the read array. I know in
the
old-school select() you could use generic events in the select
array.

Many thanks!!!

stu =)
Click to expand...
Click to expand...
Click to expand...
 
I guess by "more efficient" I mean lower cpu load. Thanks for your
help!

michael =)
I'm not sure that either is "more efficient" in either case (more efficient
at what?). It's much easier to read a multi-threaded application, because
each thread is the "same" as all the others and is relatively simple,
there's no big loop running everything. It may be harder to debug, but I'll
live with that.

Paul T.

stu said:
With select() and a single thread you can block on all sockets at once
until one of them gets something; select can listen to a whole list.
Do you think that multiple threads is still more effecient that this?
(As I said this is more of a curiosity, at this point.) Thanks for
your input!

stu =)

Well, the scheduler has to schedule all of those threads, but, unless
you're
constantly receiving packets on all of the sockets, this will be more
conservative of CPU cycles than polling and, when everything is idle,
you're
using *zero* CPU cycles because all of the threads will be blocked
waiting
for data to arrive.

Yes, when I say a single thread, I mean something that iterates over a
list
of open sockets, calling select() for each one in turn and then doing
something when a given socket has data ready to be received (or
whatever).

Paul T.

Yes, I agree async sockets were the poor choice for this. From my
knowledge, using async sockets is encouraged in big .NET (this is what
I've read, I don't have any experience in designing larger apps), so I
figured the same was true for the .netcf.

As for the single thread approach, are you talking about using
socket.select() for all sockets or using socket.poll() on each
individual socket and looping through the list (over and over and
over)?

As for the full thread approach, my fear is just eating up a lot of
resources. Is it detrimental to have upwards of 20 receive() threads
running around?

Please let me know about the single thread approach (it is more out of
curiousity at this point).

Thanks!

stu =)

Paul G. Tobey [eMVP] wrote:
It's just my own preference, but I dislike asynch sockets for
situations
like this. Yes, you can use a single dispatch thread that
continuously
runs
and checks every open socket for activity that needs a response. In
my
own
code, I'd be much more likely when using threading, to use blocking
sockets,
allowing a thread on which there is no corresponding socket activity
to
sleep, freeing up those processor cycles for threads/sockets which
*are*
active. I think that this balances the load better. Since you're on
a
very
resource-constrained device, you'll have to test to see what works
best.

Paul T.

I am looking for a good way to handle numerous sockets (1 UDP and as
many as 20+ TCP child sockets) in WM 5.0 using C# and the .NETCFv2.
Currently, I'm using async class and it works fine for small numbers
of
sockets; 1 UDP and up to 15 or so TCP child sockets. When I get to
more than 15 (or so) I have an issue with other threads, using the
threadpool, not running. Specifically, I have a managing thread
(using
the System.Threading.Timer stuff) that ceases to be called once the
number of async calls gets rather high. Do the async socket calls
block the threadpool threads? If so, is there a way to get around
this, or the is the best idea just not to use async socket calls in
this situation? I can't find any good documentation on how things
are
handled within the OS (a pointer to such documentation would be
_greatly_ appreciated, too). I was at MEDC in Vegas last week, but
failed to catch one of the VM Core developers to bug them about
this.

From looking at other posts, it seems that Socket.Select() is a much
better method for handling a large number of sockets. When using
select() is there a way to add another event that I can raise to get
select() to come back or will it only respond to socket events? For
example, I want to add another socket to the read array. I know in
the
old-school select() you could use generic events in the select
array.

Many thanks!!!

stu =)
Click to expand...
Click to expand...
Click to expand...
 
Lowest CPU load will be multiple threads, I think. You could try to test
that. It's close enough on CPU load that I wouldn't decide on that basis,
anyway. As I said, I find having separate, disconnected threads a lot
easier to manage and to scale to bigger systems.

Paul T.

stu said:
I guess by "more efficient" I mean lower cpu load. Thanks for your
help!

michael =)
I'm not sure that either is "more efficient" in either case (more
efficient
at what?). It's much easier to read a multi-threaded application,
because
each thread is the "same" as all the others and is relatively simple,
there's no big loop running everything. It may be harder to debug, but
I'll
live with that.

Paul T.

stu said:
With select() and a single thread you can block on all sockets at once
until one of them gets something; select can listen to a whole list.
Do you think that multiple threads is still more effecient that this?
(As I said this is more of a curiosity, at this point.) Thanks for
your input!

stu =)


Paul G. Tobey [eMVP] wrote:
Well, the scheduler has to schedule all of those threads, but, unless
you're
constantly receiving packets on all of the sockets, this will be more
conservative of CPU cycles than polling and, when everything is idle,
you're
using *zero* CPU cycles because all of the threads will be blocked
waiting
for data to arrive.

Yes, when I say a single thread, I mean something that iterates over a
list
of open sockets, calling select() for each one in turn and then doing
something when a given socket has data ready to be received (or
whatever).

Paul T.

Yes, I agree async sockets were the poor choice for this. From my
knowledge, using async sockets is encouraged in big .NET (this is
what
I've read, I don't have any experience in designing larger apps), so
I
figured the same was true for the .netcf.

As for the single thread approach, are you talking about using
socket.select() for all sockets or using socket.poll() on each
individual socket and looping through the list (over and over and
over)?

As for the full thread approach, my fear is just eating up a lot of
resources. Is it detrimental to have upwards of 20 receive()
threads
running around?

Please let me know about the single thread approach (it is more out
of
curiousity at this point).

Thanks!

stu =)

Paul G. Tobey [eMVP] wrote:
It's just my own preference, but I dislike asynch sockets for
situations
like this. Yes, you can use a single dispatch thread that
continuously
runs
and checks every open socket for activity that needs a response.
In
my
own
code, I'd be much more likely when using threading, to use blocking
sockets,
allowing a thread on which there is no corresponding socket
activity
to
sleep, freeing up those processor cycles for threads/sockets which
*are*
active. I think that this balances the load better. Since you're
on
a
very
resource-constrained device, you'll have to test to see what works
best.

Paul T.

I am looking for a good way to handle numerous sockets (1 UDP and
as
many as 20+ TCP child sockets) in WM 5.0 using C# and the
.NETCFv2.
Currently, I'm using async class and it works fine for small
numbers
of
sockets; 1 UDP and up to 15 or so TCP child sockets. When I get
to
more than 15 (or so) I have an issue with other threads, using
the
threadpool, not running. Specifically, I have a managing thread
(using
the System.Threading.Timer stuff) that ceases to be called once
the
number of async calls gets rather high. Do the async socket
calls
block the threadpool threads? If so, is there a way to get
around
this, or the is the best idea just not to use async socket calls
in
this situation? I can't find any good documentation on how
things
are
handled within the OS (a pointer to such documentation would be
_greatly_ appreciated, too). I was at MEDC in Vegas last week,
but
failed to catch one of the VM Core developers to bug them about
this.

From looking at other posts, it seems that Socket.Select() is a
much
better method for handling a large number of sockets. When using
select() is there a way to add another event that I can raise to
get
select() to come back or will it only respond to socket events?
For
example, I want to add another socket to the read array. I know
in
the
old-school select() you could use generic events in the select
array.

Many thanks!!!

stu =)
Click to expand...
Click to expand...
Click to expand...
 
Back
Top