Prev: No _ttof in Visual Studio 2008
Next: Handling Cut (CTRL-C) in a CListCtrl dervied control
From: Joseph M. Newcomer on 22 May 2010 12:36
See below...
On Sat, 22 May 2010 02:51:11 -0700 (PDT), bernd <bernd.schuster12(a)googlemail.com> wrote:

>thanks for your answers.
>
>more below:
>
>> ****
>> If you require the window handle to be valid, then yes, you must handle it here. �At
>> least, no earlier. �You will have to shut it down in the OnClose handler. �See my article
>> on worker threads for asynchronous shutdown techniques for threads.
>> ****>Within the user thread, I want to initalize an udp-socket.
>
>I`ll take a look at your example (shutting down a thread).
>
>> UDP is a lousy protocol for nearly anything. �Unless you are working in a very limited
>> context, VERY limited, it is going to be a royal pain to deal with. �Why do you want to
>> use UDP? �Note if your answer is "because it looks easier than TCP" then you are making a
>> VERY bad choice for the wrong reason. �
>
>The protocol (e.g. dhcp client or snmp) require to deal with udp.
****
Yes, then you are stuck with UDP. Note that these protocols ASSUME UDP transfers will
fail, and typically will do things like verify settings occurred, time out when responses
do not come in a predetermined time (they may still come!), etc.
****
>
>But in the end, I need two sockets; one for incoming udp packets and
>one for incoming tcp connection requests (for the http webserver).
>Both sockets have to be initialized at the startup of the programm. Do
>I have to install two casyncsockets with two different threads?
****
Any socket you need to make visible is unique, and is a pair <port#, protocol>, so you can
have <3, udp> and <3, tcp> both as separate sockets; this is legitimate, and is often
expected for some protocols (that there are both UDP and TCP versions supported). These
will be seen as two different sockets. Of course, if the port# is different, they will
also be seen as two different sockets.

Because CAsyncSocket doesn't block, it is your choice as to whether you handle them both
in one thread or both in different threads; in fact, it is not clear you need threads at
all. But it is always an implementation decision. Sometimes, it makes more sense to put
them in separate threads because the threads all look simpler and are therefore easier to
code (I'd probably do it that way if I were using separate threads)
joe
****
>
>best regards
>Bernd
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: bernd on 23 May 2010 07:42
thanks for your answers.

> No, you will not need two different threads.  In fact you can use both
> CAsyncSockets in the program's main thread.  The socket notifications
> (such as OnReceive) arrive as windows messages, and CAsyncSocket calls
> your OnReceive when the notification arrives, just like any other
> message handler function in your main thread.

It is a common method to create a new thread in the OnReceive-function
of CAsynSocket? The goal I want to acchieve is to process the incoming
data without affecting the working with the GUI (touch screen). So
that if a lot of data packets will arrive the user won`t noticed that.

For example: DHCP: waiting for an ip addr (getting from a dhcp server
in the network) can take a long time (if for example there`s no dhcp
server running in the network...); during this process, the user
should always be able to work with the GUI or do any other things.
Maybe there`s another way to acchieve this (without different
threads)?

Moreover: is there any algorithm already installed (using CAsynSocket)
storing all incoming packets in a list as long as these packets will
be proceed by the user function (starting from the OnReceive-Handle)?

> Sometimes, it makes more sense to put them in separate threads because the
> threads all look simpler and are therefore easier to code (I'd probably do it that
> way if I were using separate threads)

That`s of course another advantage using different threads for
different sockets.

best regards
Bernd
From: Scott McPhillips [MVP] on 23 May 2010 11:53
"bernd" <bernd.schuster12(a)googlemail.com> wrote in message
news:6bd5d856-f9f6-4a10-b779-417e77c5554e(a)z17g2000vbd.googlegroups.com...
>It is a common method to create a new thread in the OnReceive-function
>of CAsynSocket? The goal I want to acchieve is to process the incoming
>data without affecting the working with the GUI (touch screen). So
>that if a lot of data packets will arrive the user won`t noticed that.

No, that would not be a good idea. If you intend to process the incoming
data in a thread there is no advantage to putting the socket in the main
thread. Go ahead and put the socket in the data handling thread.

>For example: DHCP: waiting for an ip addr (getting from a dhcp server
>in the network) can take a long time (if for example there`s no dhcp
>server running in the network...); during this process, the user
>should always be able to work with the GUI or do any other things.
>Maybe there`s another way to acchieve this (without different
>threads)?

CAsyncSocket is non-blocking. That means it does not block the GUI. Even
if the Connect call takes a long time the call returns quicklly, then it
notifies you later with the OnConnect call.

>Moreover: is there any algorithm already installed (using CAsynSocket)
>storing all incoming packets in a list as long as these packets will
>be proceed by the user function (starting from the OnReceive-Handle)?

Nothing like that. All handling of the OnReceive data is up to you.

--
Scott McPhillips [VC++ MVP]

From: Joseph M. Newcomer on 23 May 2010 12:15
See below...
On Sun, 23 May 2010 04:42:39 -0700 (PDT), bernd <bernd.schuster12(a)googlemail.com> wrote:

>thanks for your answers.
>
>> No, you will not need two different threads. �In fact you can use both
>> CAsyncSockets in the program's main thread. �The socket notifications
>> (such as OnReceive) arrive as windows messages, and CAsyncSocket calls
>> your OnReceive when the notification arrives, just like any other
>> message handler function in your main thread.
>
>It is a common method to create a new thread in the OnReceive-function
>of CAsynSocket? The goal I want to acchieve is to process the incoming
>data without affecting the working with the GUI (touch screen). So
>that if a lot of data packets will arrive the user won`t noticed that.
****
Yes. But there is an absolutely critical trick: you must "unwrap" the SOCKET object from
the CAsyncSocket (using CAsyncSocket::Detach), pass the raw SOCKET across the thread
boundary, and rebind it (using CAsyncSocket::Attach) in the thread. See my essay on UI
threads on my MVP Tips site.

The reason for this is that handle maps are thread-local and therefore you will get really
nasty failure modes if you just pass a pointer to the CAsyncSocket across the thread
boundary.
****
>
>For example: DHCP: waiting for an ip addr (getting from a dhcp server
>in the network) can take a long time (if for example there`s no dhcp
>server running in the network...); during this process, the user
>should always be able to work with the GUI or do any other things.
>Maybe there`s another way to acchieve this (without different
>threads)?
****
Because you are working with asynchronous sockets, you don't need a thread at all. The
socket will cause a notification to be sent to your handler at the point where the
notification is required, and nothing blocks. That's why they are called "Asynch"
sockets.
****
>
>Moreover: is there any algorithm already installed (using CAsynSocket)
>storing all incoming packets in a list as long as these packets will
>be proceed by the user function (starting from the OnReceive-Handle)?
****
When you get data from a CAsyncSocket, what you do with it is your business. If you need
a list of these, it is your responsibility to write code to do this.

Because you are using UDP, you need to do the Receive as soon as you can; if you leave the
packet in the network stack, it might be discarded to make room for more, or other packets
coming in might be discarded because your packet is hogging resources. Therefore, any
storage is your application's responsibility.
****
>
>> Sometimes, it makes more sense to put them in separate threads because the
>> threads all look simpler and are therefore easier to code (I'd probably do it that
>> way if I were using separate threads)
****
Most people don't recognize that one of the uses of threads is to simplify coding; often
this is more compelling than the need for asynchrony. But with CAsyncSocket, all the
logic is already in the virtual methods of the class, and it doesn't care what thread is
being used, so it doesn't matter whether you have one thread or fifty.
****
>
>That`s of course another advantage using different threads for
>different sockets.
****
Yes, but as I just pointed out, there's no real advantage in this for asynchronous
sockets. It really only deals with whether or not each packet requires a lot of
processing and therefore would interfere with the GUI processing.
joe

joe
****
>
>best regards
>Bernd
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  | 
Pages: 1 2
Prev: No _ttof in Visual Studio 2008
Next: Handling Cut (CTRL-C) in a CListCtrl dervied control