Dennis Windisch wrote: > For testing purposes I've written a server and a client task running on two > differnt machines, which exchanges messages via non RT UDP-sockets. > Then I made the socket in the server-task a RTnet RT socket. When I tested > the so modified task again (only changes were adding the _rt suffixes), > nothing works. The server-task didn't receive the messages of the > client-task (which is non RT) and vice versa.
Did you turned your server-task into a RT task as well? That's required to send and receive messages over RTnet. Take a look at some of the (few) existing RTnet examples for your RT-Linux extension. Just an additional note: turning some arbitrary application into a real-time application is very seldom only about replacing function calls, libraries, or OSes, it's often also about replacing the application design (e.g. re-allocation of resources). > I know RT-sockets are not thought to be comunicating with non-RT sockets and > in my final implementation this wouldn't be the case of course. But because > I can only run RTAI/RTnet on the server (client uses other RTOS), I just > wanted to test what happens when I let a RT(net)-socket communicate with an > other kind of socket. It's not about socket communication, it's rather about compatible protocols and media access control. One compatible protocol of RTnet is UDP/IP. There is existing code in the RTnet example folder which could also be used to test mixed scenarios like yours. Just be warned that the determinism of your whole setup now depends on the likely unknown RT characteristics of the other OS's IP stack. It's likely best to avoid any traffic besides critical payload on that node, so that no potential contentions in that stack can cause unexpected sporadic delays. > Because nothing changed in my server task except adding _rt suffixes to the > corresponding socket/bind/recvfrom/sendto, I'm unsure how to interpret this > result I get. A good starting point is to look at error codes returned by those functions. > Is it generally not possible that RT(net)-sockets communicate with other > sockets? By the way, are sockets created with socket_rt blocking or > non-blocking (are both modes possible)? Or what am I doing wrong or have > overlooked to do? Default behaviour when trying to receive messages from a RTnet-socket without data pending is blocking (this was different only in very old RTnet versions). Actually, yet overlooked bugs aside, the socket API of RTnet should comply with core POSIX socket characteristics. Jan
signature.asc
Description: OpenPGP digital signature
