40006 error not trapped by SessonError

[jstirn]

A Client of ours is experiencing timeout errors that appear to be random.  We have also experienced 40006 errors that occur now rarely but do occur.  It seems that the 40006 error is not be trapped by the SessionError method.  The client has a valid Lic. key (word 'demo' does not appear in the title caption)...

How can we keep the application from crashing and trap these errors?

[leet]

The SessionError method in RFSDK 6.0.0 traps all Winsock errors.  Error 4006 is "Wrong protocol or connection state for the requested transaction or request," so your client's TCP connection dropped unexpectedly.  Please let me know what version of RFSDK you are using so that I can look into it.

Timeout errors are usually due to other circumstances and is usually either related to RF connectivity, network latency, or complex processing code.  If your application is running large or complex queries or updates that take more than a second or two to process, the clients can be dropped.  The RFStatus method is like a "ping" to keep the client connection alive, and can be used during the long transaction to keep portables from timing out.  

If you are not running long queries, check into their RF Network.  If you are on a large network, ensure that all unnecessary protocols are filtered out by the Access Point.  Filtering by IP or MAC address can also reduce RF traffic.  

Access points in close proximity that are on the same channel can cause connectivity problems.  If there are multiple access points in the building, try turning off all but one of them and running the app.

Lee Tibbett
IntelliTrack

[jstirn]

Thanks,

We are using 6.0.0, and yes there are long queries in key areas.  
I'll be adding the RFStatus Method - Thanks for the TIP!

This particular Client uses only one Access point.  We have recently separated the application into two pieces (see my previous topic P.S. thanks for the help).  Additionally, we changed the way the sessions were being started/created (Dynamically to static - like the demo code).  Those changes greatly reduced the occurances of 40006 from one to two times a day to once in two to three weeks!  I thought we had trapped the error in SessionError to log them and keep the app from crashing... Least that was the intent

[jstirn]

Any new progress on the topic?

[leet]

I have not found any issues in the RF SDK.  We have seen screens get out of sequence due to improper error handling and shifting from screen to screen without going through the proper sequence of events.  I would try running one of the demonstration programs that came with the RF SDK.  If they do not experience the same error (40006), then it is definitely a problem in your application's code.  The sample applications show how to navigate from one screen to the next.  There is also an application template that you can use to begin writing your own RF application.

We have been using the RF SDK for our internal products and custom programs since its creation.  If you cannot find the problem, the IntelliTrack Software Services department can look over your code for a fee.  Contact your reseller for information on pricing.

Lee Tibbett
IntelliTrack

[jstirn]

Thanks Lee,

We are moving toward checking each and every screen.  Its a large app.

I understand that the occurance of the error is most likely the application code.  However, does the SDK trap the error?  I'm assuming that its being rasied by MS Socket layer...  I'm looking to trap and handle the errors with out crashing the controller.

[leet]

The RF controls do forward the error to your application.  Put error handling in every screen function along with the "display screen" function if you used the template project.  Also, make sure that you don't call a screen function without first going through the whole process of "display screen." In other words, do not jump around from one screen to another without returning properly, because the portables do not receive their reset commands which get ready for the next screen.  When the screens get out of sync, the application has gone from one screen to the next due to an error or due to coding in the application.

Lee Tibbett
IntelliTrack

[jerryz28]

Did you ever find out what was causing your 40006 errors? We are currently receiving them once a week which causing the application to crash and need to be reset.

[leet]

Lately we've seen some conditions where Symbol (Motorola) access points were causing portables to drop frequently and therefore causing the 40006 errors.  By upgrading the firmware on the access points the condition went away.

We have recently updated the latest RFSDK to handle 40006 internally by explicitly testing for an open connection before sending any data.  If the connection has dropped, the session will end and the server will move on.  This is more or less a bandaid because the portable still loses its connection due to external conditions, and under certain conditions the server could still crash depending on timing.  The underlying issue with the network connections are still the actual cause of the errors and are beyond our control.  If you have version 7.x with a current support agreement the upgrade is available to you free of charge under our minor release policy.

[adamlevine76]

I have not discovered any concerns in the RF SDK.  We have seen displays get out of series due to inappropriate mistake managing and moving from display to display without going through the appropriate series of activities.  I would try managing one of the demo applications that came with the RF SDK.  If they do not encounter the same mistake (40006), then it is definitely a issue in your application's value.  The example applications display how to get around from one display to the next.  There is also an program design that you can use to start composing your own RF program.