Alaska Software Inc. - SocketRecv question???
Username: Password:
AuthorTopic: SocketRecv question???
Jim GrahamSocketRecv question???
on Thu, 11 Jan 2007 08:55:09 -0500
I am using the SocketSend() & SocketRecv() functions to communicate with 
another program/device.

When I send a command to the destination device, it responds with an "Ok" or 
"Error".  The problem is that if I send a bad command the device does not 
respond so the SocketRecv() funtion just sits there waiting forever.

My question is:  How do you get the SocketRecv() function to timeout after 
"n"???


Thanks in advance for any help!


Here are the 2 methods of the class I use to do TCP/IP communications:

Method PITAS_CenturiSoftVoiceLoggerInterface:SendTCPIP( pcCommand )

   Local lbSuccess := .T.
   Local lnI       := 0
   Local lcReturn  := Nil

   ::cReceiveMessage := ""

   For lnI := 1 To  ::nTCPIPAttempts

      If SocketSend( ::nSocketHandle, pcCommand ) == 0
         If  SocketGetLastError() > 0
            ::cReceiveMessage := "TCPIP error - Unable to send data to: " + 
::cTCPIPAddress + " Error # " + AllTrim( Str( SocketGetLastError() ) )
            lbSuccess := .F.
            Exit
         Endif
      Else

        If !Empty(lcReturn := ::ReceiveTCPIP())
           If Left(lcReturn,2) = "OK"
              lbSuccess := .T.
           Else
              lbSuccess := .F.
           Endif
           ::cReceiveMessage := lcReturn

           Exit
        Endif

      Endif
   Next

Return lbSuccess

Method PITAS_CenturiSoftVoiceLoggerInterface:ReceiveTCPIP()

   Local lcReceiveBuffer := Space(1)
   Local lnBufferLength  := Len(lcReceiveBuffer)
   Local lnI
   Local lcReceived      := ""

   For lnI := 1 To DEF_READ_CHARACTER_MAX
       DCQOUT "Read char", lnI
       If SocketRecv( ::nSocketHandle, @lcReceiveBuffer, lnBufferLength, 
MSG_NORMAL ) <= 0
           Error trapping
          Exit
       Else
          If lcReceiveBuffer == Chr(10)        Line Feed, wev'e got it all
             Exit
          ElseIf lcReceiveBuffer != Chr(13)    Read until carriage return
             lcReceived += lcReceiveBuffer
          Endif
       Endif
   Next lnI

Return (lcReceived)
Phil Ide
Re: SocketRecv question???
on Thu, 11 Jan 2007 15:10:00 +0000
Jim,


> When I send a command to the destination device, it responds with an "Ok" or 
> "Error".  The problem is that if I send a bad command the device does not 
> respond so the SocketRecv() funtion just sits there waiting forever.
> 
> My question is:  How do you get the SocketRecv() function to timeout after 
> "n"???

Oh, what a bad device.

Never mind, several things you can do. The easiest method is to set the
socket to non-blocking, then loop while there is no data (or insufficient
data) on the socket.  As you loop, you can monitor the time you have waited.

Another alternative is to set the socket to monitor events.  In this mode,
you don't do anything with the socket as such.  In your event loop, when a
socket arrives arrives, you call the routine to respond to it (the socket
handle is one of the parameters of the event).  The event will identify one
of the following conditions:

1. RECV - data waiting on socket
2. ACCEPT - connection from remote on socket
3. SEND - if you tried to send data and the socket was full,
   you get this message when the socket is empty and ready to send more data
4. CLOSE - when socket gets disconnected

The actual messages and parameters can be found in the Platform SDK.

You need to create a Windows(TM) window and supply your own WndProc and
event handler, so needs to be done in C or Cockpit, but it's not hard and
allows you to just plug-n-prey with your send/recv routines.

Boris can probably tell you more about setting up timeouts - I've not tried
playing with those (when I need timeouts, I just use Xb2.NET).

Regards,

Phil Ide

---------------------
www.xbhcl.com
www.pbih.eu
www.idep.org.uk/xbase
---------------------
I'm not an actor, I just play one on TV.
Jim GrahamRe: SocketRecv question???
on Thu, 11 Jan 2007 10:36:13 -0500
Thanks Phil!

Short term I think I will change the "Blocking Mode" and implement my own 
timer...

Long Term, I will switch to XB2NET...


Best regards,

Jim



"Phil Ide" <phil@idep.org.uk> wrote in message 
news:xuygs6z4m1zo$.1jj3oa5d64iz8$.dlg@40tude.net...
> Jim,
>
>
>> When I send a command to the destination device, it responds with an "Ok" 
>> or
>> "Error".  The problem is that if I send a bad command the device does not
>> respond so the SocketRecv() funtion just sits there waiting forever.
>>
>> My question is:  How do you get the SocketRecv() function to timeout 
>> after
>> "n"???
>
> Oh, what a bad device.
>
> Never mind, several things you can do. The easiest method is to set the
> socket to non-blocking, then loop while there is no data (or insufficient
> data) on the socket.  As you loop, you can monitor the time you have 
> waited.
>
> Another alternative is to set the socket to monitor events.  In this mode,
> you don't do anything with the socket as such.  In your event loop, when a
> socket arrives arrives, you call the routine to respond to it (the socket
> handle is one of the parameters of the event).  The event will identify 
> one
> of the following conditions:
>
> 1. RECV - data waiting on socket
> 2. ACCEPT - connection from remote on socket
> 3. SEND - if you tried to send data and the socket was full,
>   you get this message when the socket is empty and ready to send more 
> data
> 4. CLOSE - when socket gets disconnected
>
> The actual messages and parameters can be found in the Platform SDK.
>
> You need to create a Windows(TM) window and supply your own WndProc and
> event handler, so needs to be done in C or Cockpit, but it's not hard and
> allows you to just plug-n-prey with your send/recv routines.
>
> Boris can probably tell you more about setting up timeouts - I've not 
> tried
> playing with those (when I need timeouts, I just use Xb2.NET).
>
> Regards,
> -- 
> Phil Ide
>
> ---------------------
> www.xbhcl.com
> www.pbih.eu
> www.idep.org.uk/xbase
> ---------------------
> I'm not an actor, I just play one on TV.