vxWorks networking quirks?

[virtuald]

Does anyone have any experience with vxWorks and its networking stack? In particular, I'm wondering if anyone is aware of any quirks of the vxWorks stack that make it different enough from a normal BSD stack that could cause annoying errors if one wasn't aware of it.

I'm trying to use boost::asio to do this, so that I can run the project on my local machine and on vxWorks without too many problems. It took a small bit of effort to port asio to vxWorks, since theres a few type oddities that exist, and the open/ioctl calls vary slightly, but for the most part the patch was pretty trivial.

I'm using a modified version of the asio webserver example, and I have the thing working perfectly on my windows box.

However, on the cRio for whatever reason when serving pages, the buffers keep getting mixed up and it sends invalid data (but only for large files), and additionally it will sometimes *keep* sending data (hundreds of megabytes in fact) until some error occurs. This makes me suspect that one or more of the vxworks network calls are returning something that the asio code isn't expecting, and so it thinks that the data hasn't really been sent. Or something to this effect.

Any thoughts anyone could provide would be great.

[virtuald]

I found the error, it was a bug in asio. Turns out that vxWorks has a rather small send buffer, or at least small enough where the call ends up blocking while partially transmitting the buffer. Asio didn't adjust for that. Since most modern OS don't have a small buffer like that, apparently nobody has caught that error (and in fact, I wasn't able to duplicate it on a non-cRio platform).

Filed a bug at https://svn.boost.org/trac/boost/ticket/2953

I've now got boost::threads and boost::asio working on vxWorks correctly. Let me know if you're interested, I'll be releasing a patchset soon.

[virtuald]

I've released the patchset here: http://www.virtualroadside.com/blog/...s-for-vxworks/