It's about a mechatronical system that needs to be controlled via software. It is not yet clear in which language it will be written, but since it is not important, let's just say in Java.
The 1. thing is that we will need to send messages via CAN. So we have the control software, some event happens and we send a message via CAN. The mechatronical system will react.
Now the 2. thing is that obviously it would be good to be able to test the software without a real mechatronical system, since it reduces effort. So I thought about writing another program, a simulation program.
So I imagine that the simulation program notices when a CAN message is sent and reacts to it.
How is a good approach to accomplish that?
I mean for the real mechatronical system the control software needs to send a CAN message directly on the bus(, maybe via some native code). For the simulation program some kind of interprocess communication is needed. How must the control software be designed that it doesn't care if there is some simulation program that is listening or a real mechatronical system that gets the CAN messages?
My first thought was that the control software always sends "CAN messages" via an interprocess communication approach. Let's say for the sake of simplicity it is RMI. Then to send real CAN messages via the bus there is some module in the same control software that gets the "CAN messages" via RMI and forwarding them to the real CAN bus.
Now the simulation program is able to receive the "CAN messages" via RMI, too, and can react to it.
Is that a good approach? Because I see that there is some overhead in the control software by communicating to itself via interprocess communication, which is not neccessary in principle. But I see no other possibility to have an abstraction layer, such that I have no special code for the simulation program in the control software.
Thank you for feedback!
You're describing one aspect of Hardware-in-the-loop testing. It's a standard approach for developing mechatronic systems that combine software and hardware.
In a software setting one way to solve this problem is to provide an interface (as in a Java interface, rather than a physical one). You end up with two concrete implementations of that interface, one for your real hardware, and one for your test version. Because the real and test versions provide the same interface, they should be interchangeable.
Once you've got your interfaces described how you implement them should be irrelevant (ie/ you could use a scripting language to develop the test code more quickly or cheaply) - so RPC may be a possibility, but there are certainly other choices.
Related
Given the server-client model, would the OS initiate messages to applications, or is message passing always initiated by programs that want to use resources and thus must communicate with the OS?
OS is an overloaded term, and application is a vague term.
A pure message passing OS might implement traditional (unix) system calls in applications. For example, you might have an application called FileSystem, which accepts messages like Read,Write,Open,Close.... In these, such an application would be considered a server, and the client would be an application which wanted to use the File Services.
Pure message passing systems typically have difficulty with asynchronous events. When you look at implementing a normal read system call in a message passing system, it is natural that it will be an RPC: the client sends a read request, then suspends until the server has satisfied the read and sent a reply.
When the client wants asynchronous notification, such as send me a message when there is new mouse events available; the RPC somewhat falls down. While purely asynchronous systems exist, they are cumbersome to use with plain old programming languages like C, C++, ... There is hope that message based languages like Golang can break the impass, but that is yet to be seen.
Higher level OS-like services may deploy a number of interaction methods, quite distinct from client serve. Publish-Subscribe, a more recent reimplmentation of the 1980s multi-catch, has been popular in the last decade. Clients subscribe to a set of channels that they are interested in, and every event delivered to that channel is copied to every client subscribed to the channel before it is retired. Normal clients can generate events as well, so the mechanism serves as a dynamic interconnect between modules.
Dbus + zeromq are P-S systems of differing scales. Note that both can be implemented outside of a message passing OS.
What is the actual difference between Socket and RPC (Remote Procedure Call)?
As per my understanding both's working is based on Client–server model. Also which one should be used in which conditions?
PS: Confusion arise while reading Operating System Concepts by Galvin
Short answer:
RPC is the protocol. The socket provides access to the transport to implement that protocol.
RPC is the service and protocol offered by the operating system to allow code to be triggered for running by a remote application. It has a defined protocol by which procedures or objects can be accessed by another device over a network. An implementation of RPC can be done over basically any network transport (e.g. TCP, UDP, cups with strings).
The socket is just a programming abstraction such that the application can send and receive data with another device through a particular network transport. You implement protocols (such as RPC) on top of a transport (such as TCP) with a socket.
It is operating system specific. So read first a good OS book like Operating Systems: Three Easy Pieces (freely downloadable).
Network sockets are a way to do some inter-process communication (notably between different machines). Read also about Berkeley sockets API, e.g. socket(7) on Linux.
Remote procedure calls are a programming technique (often using socket(2) system call on Linux). Every RPC request expects exactly one reply and is software initiated.
Sockets are often also used for asynchronous messages (for example, the X11 protocols stack, WebSockets, SMTP). Message passing is a programming paradigm (more general than RPC), they are sent often without expecting any reply. For example, the X11 server would send a keyboard event message for every key press, etc.
(so in some ways, you are comparing apples and oranges)
If on Linux, I recommend reading Advanced Linux Programming (freely downloadable), and reading more about syscalls(2) (notably poll(2) for multiplexing)
PS: Confusion arise while reading Operating System Concepts by Galvin
That's your problem right there.
A remote procedure call (RPC) is high level model for network communication. There are numerous RPC protocols in existence. In the RPC model, your underlying implementation creates a stub for each remote procedure. When your application calls the "remote procedure" the stub packs up the parameters, sends them over the network, invokes, the remote version of the procedure, takes the return values and send them back over the network to the caller, the stub unpacks the return values and your application then receives them.
The RPC model became hip in the late 1980's. The idea was that it would be transparent where your functions actually executed (in your process, in another process, on another computer). This concept expanded into distributed objects around the early 1990's (e.g., DCOM, CORBA).
Unfortunately, in the real world applications really needed to know if a procedure was executing remotely because of delay and error handling.
Somewhere in the the RPC implementation a network interface gets called.
Sockets are such a network interface. They are not the only programming interface but they are the most common on Unix systems.
Thus, an RPC MIGHT be implemented using a socket.
I have several years experience with microcontroller programming. Freertos provides the necessary code to port to a set of microcontrollers. I would like to port Freertos to an embedded system which is not supported.
Which main steps have to be undertaken in order to successfully port freertos to another embedded system? (for example: what initialization steps should absolutely be done in port.c etc...) I have read the freertos page about porting, but it is still pretty vague.
I presume this is the page you are referring to http://www.freertos.org/FreeRTOS-porting-guide.html it is vague because each architecture has its own requirements. For example, is a yield going to be performed synchronously using a trap style instruction, or asynchronously using a pended interrupt, how is interrupt nesting going to be implemented and what support does the hardware give to implement it, etc. Therefore it would have helped a lot if you said which architecture you wanted to port to, then I might have been able to suggest which port to look at as a reference.
I am communicating across USB, using a proprietary protocol, with some custom hardware I've built. I have a GUI that handles all the communications/interaction with that hardware and a (C#) DLL which exposes all the relevant USB functionality. I need to write a LabVIEW driver (VI) for communicating with the hardware. My thought is that I just use LabVIEW to open up my GUI and have a socket with which I expose all the relevant control to LabVIEW with. Is it possible to open a socket in LabVIEW and communicate with my GUI? Is this a bad approach or should I just try and make LabVIEW invoke the DLL and handle the hardware control instead of my GUI (polled communications, solicited/unsolicited commands, etc)?
IS there a reason you want to use your GUI only? In terms of time, I would say build a good front panel in LabVIEW and just communicate to the hardware directly using the DLL. Adding the GUI is just an added layer of complexity which might be difficult to maintain later on? Why not do everything in LabVIEW if you can?
Yes, LabVIEW supports sockets using both TCP/IP and UDP.
You should be able to create a program/service that continually runs acting as TCP/IP server. You can send commands and receive responses as strings. If you need to pack data, you can use the flatten to string command.
Essentially, your application should be structured as a loop running the TCP/IP server, and another loop that actually communicates with the instrument. This might change if you need to get data back from the devices to your TCP client. A producer consumer model, if you will :)
To get you started off, open up the NI Example Finder (Help -> Find Examples) and browse to Networking->TCP and UDP-> Simple Data Server.vi
It depends who is going to be using the LabVIEW driver and for what. If you're handing over this hardware to someone else who is going to want to create their own application(s) for it, they would probably prefer to talk directly to the DLL rather than go through your GUI. If it's more about automating your existing software from LabVIEW to do testing or repetitive tasks on the hardware, for example, then driving your GUI from LabVIEW might be less work.
I plan on writing an automated bot for a game.
The tricky part is figuring out how they encoded their protocol... To make the bot run around is easy, simply make the character run and record what it does in wireshark. However, interpreting the environment is more difficult... It recieves about 5 packets each second if you are idle, hence lots of garbarge.
My plan: Because the game runs under TCP, I will use freecap (http://www.freecap.ru/eng) to force the game to connect to a proxy running on my machine. I will need this proxy to be capable of packet injection, or perhaps a server that is capable of resending captured packets. This way I can recreate and tinker around with what the server sends, and understand their protocol encoding.
Does anyone know where I can get a proxy that allows packet injection or where I can perform packet injection (not via hardware, as is the case with wireless or anything!)
Where of if I can find a server/proxy that resends captured packets (ie: replays a connection).
Any better tools or methodologies for pattern matching? Something which can highlight patterns from mutliple messages would be GREAT.
OR, is there a better way to decipher this here? Possibly a dissasembly strategy (via hooking a winsock function and starting the dissassembly from there) ? I have not done this before so I am not sure. OR , any other ideas?
Network traffic interception and protocol analysis is generally a less favored method to accomplish your goal here. For most modern games, encryption is a serious factor, and there are serious headaches associated with the protocol analysis for any but trivial factors of the most common gameplay scenarios.
Most modern implementations* of what you are trying to do rely on reading and manipulating the memory space and process of a running client. The client will have already done all the hard parts for you, including decrypting the traffic and sorting it into far more easy to read data structures. For interacting with the server you can call functions built into the client instead of crafting entire series of packets from scratch. The plus to this approach is that you have to do far less work to interpret the data and produce activity. The minus is that there is often some data in the network traffic that would be useful to a bot but is discarded by the client, or that you may want to send traffic to the server that the client cannot produce (which, in my own well-developed hierarchy for such, is a few steps farther down the "cheating" slope).
*...I say this having seen the evolution of the majority of MMORPG botting/hacking communities from network protocol analyzers like ShowEQ and Odin's Eye / Excalibur to memory-based applications like MacroQuest and InnerSpace. On that note, InnerSpace provides an excellent extensible framework for the memory/process-based variant of what you are attempting, and you should look into it as a basis for your project if you abandon the network analysis approach.
As I've done a few game bots in the past (for fun, not profit or griefing of course - writing game bots is a lot of fun), I recommend the following:
If you can code and there isn't cheat protection preventing you from doing it, I highly recommend writing an injected DLL for the following reasons:
Your DLL will be able to access the game's memory space directly, and once you reverse-engineer the data structures (either by poking around memory or by code disassembly), you'll have access to lots of data. This will also allow you to bypass any network encryption the game may have. The downside of accessing process memory directly is that offsets and data structures change between versions - however, data structures don't change very often with a stable game, and you can compensate offset changes by searching for code patterns instead of using fixed offsets.
Either way, you'll still be able to hook WinSock functions using API hooks (check out Microsoft Detours and the excellent but now-commercial madCodeHook).
otherwise, I can only advise that you give live/interactive packet editors like WPE Pro a try.
In most scenarios, the coolest methods (code reverse-engineering and direct memory access) tend to be the least productive. They require a lot of skill (to understand the code) and time, both initially (to go through all the code and develop code to interact with the data structure) and for maintainance (in case the game is being updated). (Of course, they sometimes do allow doing cool stuff which is impossible to do with the official client, but most of the time this is obvious as blatant cheating, and likely to attract the GMs quickly). Most of the time bots are made by replacing game graphics/textures with solid colours, and creating simple "pixel" bots which search for certain colours on the screen and react accordingly (e.g. click them).
Hope this helps, and remember - cheating is only fun when it doesn't make the game less fun for everyone else ;)
There are probably a few reasonable assumptions you can make that should simplify your task enormously. However, to make the best use of them you will probably need greater comfort with sleeves-rolled-up programming than it sounds like you have.
First, it's a safe bet that the encryption they are using falls into one of three categories:
None
Cheesy
Far better than you are likely to crack
With the odds of the middle case being very low.
Next, it's a safe bet that the packets are encrypted / decrypted close to the edge of the program (right as they come in, right before they go out) and that the body of the game deals with them in decrypted form.
Finally, the protocol they are using most likely consists of either
ascii with data blocks
binary goo
So do a little packet sniffing with a card set in promiscuous mode for unencrypted ascii. If you see some, great, you're ahead of the game. But if you don't give up the whole tapping-the-line idea and instead start following the code as it returns from the sending data out by breakpointing and stepping with a debugger. Figure the outermost layer or three will be standard network stuff, then will come the encryption layer, and beyond that the huge mass of stuff that deals with the protocol unencrypted.
You should be able to get this far in an hour if you're hot, a weekend if you're reasonably skilled, motivated, and diligent, and never if you are hopeless. But it is possible in principle (and doubtlessly far easier in practice) to do it this way.
Once you get to where something that looks like unencrypted goo comes in, gets mungled, and the mungled form goes out, then start worrying about what it means.
-- MarkusQ
A) I play a MMO and do not support bots, voting down...
B) Download Backtrack v.3, run an arpspoof on your default gateway and your host. There is an application that will spoof the remote host's SSL cert sslmitm (I believe is the name) which will then allow you to create a full connection through your host. Then fireup tcpdump/ethereal/wireshark (choose your pcap poison) and move around do random stuff to find out what packet is doing what. That will be your biggest challenge; but proxying with a Man in the Middle attack on yourself is the way to go.
C) I do not condone this activity, this information is only being provided as free information.
Sounds like there is not encryption going on, so you could do a network approach.
A great place to start would be to find the packet ID's - most of the time, something near the front of the packet is going to be an ID of the type of the packet. For example move could be 1, shoot fired could be "2", chat could be "4".
You can write your own proxy that listens on one port for your game to connect, and then connects to the server. You can make keypresses to your proxy fire off commands, or you can make your proxy write out debugging info to help you go further.
(I've written a bot for an online in game in PHP - of all things.)