Problem with Socket Extender (wwwsk44i.dll) - sRecvLine() function

[snowsnowsnow]

Here is the code I am using - it works fine in WB 2006D (with wwwsk34i.dll):

Code (winbatch) Select Expand

unixsocket = sOpen()
IF !sConnect(unixsocket,Param1,Param2) THEN goto errExit

:loop
Line = sRecvLine(unixsocket,100)

Param1 and Param2 are a host and port to connect to.

The problem is that in the latest WB, with the latest Socket Extender, the sRecvLine returns after about 10 seconds.  In the previous version, it would wait forever, until something was available (i.e., the server sent a line of text down the pipe).

In the current version, it returns and a subsequent call to wcGetLastErr() returns the value 20.  According to the dox, 20 is "Unknown failure".

So, I work around this by calling wxGetLastErr() after the sRecvLine() and if it returns 20, I do: TimeDelay(2) and goto loop.

As I say, it worked fine before.  Is this a bug?

Also, does the sRecvLine() call burn the CPU?  I couldn't quite tell, so I put in the TimeDelay(2) just to be safe.  Is that necessary?

[td]

As far as I know, nothing has changed in the functionality of the extender with regard to timing since it was initially released back in 1998.  You can check the extender's readme file for descriptions of changes made over the years.  The extenders recieve timeout has always defaulted to 10 seconds but you have always been able to change it using the wxParmSet function.  The max time is around max four-byte signed integer if I recall correctly. You are correct about the 20 error. It is the result of a timeout.

The extender consumes very little CPU time when waiting to receive on a port.  It uses the thread message queue to suspend the process.

[edit] Note that you can use the extender's wxGetErrDesc function to get a more detailed error description.

[snowsnowsnow]

You know, now that I think about it, I think you're right.  I think it has always been this way.

In the past, I think I've kludged around it in other ways.

But don't you think the documentation for sRecvLine() should be updated to include some mention of the
timeout?  Currently, it does not.  It certainly sounds like it would just wait (forever) for data to
appear.  Why is this timeout functionality there anyway?  What purpose does it serve?  I could see it as
an optional feature (more about this below), but it should not be on by default.

Maybe the syntax could be enhanced to soemthiing like:

    Line = sRecvLine(sock,maxsize[,timeout])

I.e., an optional 3rd parameter specifying the timeout.

Also, surely the documentation for the error codes should be updated so that code 20 mentions being a
timeout value, rather than just "Unknown failure".

Anyway, I think the way one is "supposed" to handle this is to use sOK2Recv(), before calling
sRecvLine(), like this:

    WHILE !sOK2Recv(sock,1)
   TimeDelay(1)
    ENDWHILE
    Line = sRecvLine(sock,maxsize)

But the point is this should all be documented better.