Lpc2000

Hi All

This may seem a bit off topic - which it is as well - but I think 
that some of you may be able to help. I did expressly join a 
reasonably active looking VisualC++ group only to find out that 99% 
of its content is advertising or job recruitment and so don't have 
much hopes to receive anything worth while...

So here is the question:
Does any one have experience with timeout limits of CSocket socket
implementation? [MFC and a bit like BSD socket support]
CSocket used CAsyncSocket and I am using it to send and receive UDP
frames. When a read is made it blocks until it receives something,
which is not what I need for my present project. What I need is the
possibility to tell it to return after a specified time (say 1 or 2
seconds if it doesn't receive anything).
I was expecting the timeout to be set using CAsyncSocket::SetSockOpt
but it turns out that this supports a subset of BSD sockets (where
the setting is possible here) but doesn't support the setting I am
looking for.
So at the moment I doen't seem to find a solution.

As you can imaging the embedded processor side is not the problem 
here but it often has to communicate with a PC - windows in this 
case..

Can anyone help??

Regards

Mark Butcher
www.mjbc.ch

I think your question is way off topic! Most people here hate 
windows and windows programing. Lets hope someone can help you

Gus
--- In lpc2000@yahoogroups.com, "Mark Butcher" <M_J_Butcher@I...> 
wrote:
>
> Hi All
> 
> This may seem a bit off topic - which it is as well - but I think 
> that some of you may be able to help. I did expressly join a 
> reasonably active looking VisualC++ group only to find out that 
99% 
> of its content is advertising or job recruitment and so don't have 
> much hopes to receive anything worth while...
> 
> So here is the question:
> Does any one have experience with timeout limits of CSocket socket
> implementation? [MFC and a bit like BSD socket support]
> CSocket used CAsyncSocket and I am using it to send and receive UDP
> frames. When a read is made it blocks until it receives something,
> which is not what I need for my present project. What I need is the
> possibility to tell it to return after a specified time (say 1 or 2
> seconds if it doesn't receive anything).
> I was expecting the timeout to be set using 
CAsyncSocket::SetSockOpt

> but it turns out that this supports a subset of BSD sockets (where
> the setting is possible here) but doesn't support the setting I am
> looking for.
> So at the moment I doen't seem to find a solution.
> 
> As you can imaging the embedded processor side is not the problem 
> here but it often has to communicate with a PC - windows in this 
> case..
> 
> Can anyone help??
> 
> Regards
> 
> Mark Butcher
> www.mjbc.ch
>

I know what you mean Gus. I am going blind looking through the docs. 
Hope some one has an answer so that I can get on with the enbedded 
stuff again...

Regards

mark
--- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:

>
> I think your question is way off topic! Most people here hate 
> windows and windows programing. Lets hope someone can help you
> 
> Gus

I'd use the Windows Sockets 2 API which has select().

Regards
Michael

>I know what you mean Gus. I am going blind looking through the docs. 
>Hope some one has an answer so that I can get on with the enbedded 
>stuff again...
>
>Regards
>
>mark
>--- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:
>  
>
>>I think your question is way off topic! Most people here hate 
>>windows and windows programing. Lets hope someone can help you
>>
>>Gus
>>    
>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Michael Johnson wrote:
> I'd use the Windows Sockets 2 API which has select().
> 
> Regards
> Michael
> 
> 
>>I know what you mean Gus. I am going blind looking through the docs. 
>>Hope some one has an answer so that I can get on with the enbedded 
>>stuff again...

How much host-side programming are you thinking of doing?
I gave up writing lower level code a year or so ago, and
bit-the-bullet and starting using ACE

http://www.cs.wustl.edu/~schmidt/ACE.html

Its a set of C++ classes and 'frameworks' (templatized
application components, like servers and client
connection steps) that operate across Linux, Solaris,
Windows, VxWorks, RTEMs, etc.

There are three books on the subject;

   C++ Network Programming Volume 1
   C++ Network Programming Volume 2
   The ACE Programmers Guide

If you think you might be interested in using this, feel free
to ask me questions.

I personally have not used UDP for comms, I use TCP. So don't have
any specific comments there. However, the ACE classes are all
setup with timeouts and connection control logic.

Cheers
Dave

> http://www.cs.wustl.edu/~schmidt/ACE.html
>
> I personally have not used UDP for comms, I use TCP. So don't have any
> specific comments there. However, the ACE classes are all setup with
> timeouts and connection control logic.


We've used ACE for UDP as well as TCP/IP and even SSL.  Works great.

(ACE also works for other OS's such as Linux and uCLinux, and even
though it is not really mainstream, ARM processors.  The interface is
identical across all of these OS's and processors.)

Hi and thanks for the tips.

It seems as though the simplest method to get the code working as I 
want it is to move to the Windows Sockets 2 API and use the select() 
support.

Many thanks again.

Regards

Mark Butcher
www.mjbc.ch