I'm looking into C/C++ libraries (Win/Linux) that allow me to synchronize information over network. I want to run multiple instances of my program (on different PC's), and want to synchronize files locally instead of accessing files remotely over the network at a single location.
If all instances are to maintain DB consistency it also needs to bee aware of any message delivery errors, so an ack mechanism is necessary.
I stumbled into a couple of solutions, but I'm still trying to figure out what my best solution would be.
Any suggestions are appreciated and feel free to ask about any clarifications.
Edit
I've been looking into enet and UDT does anyone has any experience using them?
I think the design space for such a thing is pretty huge, but it reminded me of a kinda cool library I saw the other day, VAST. The idea is that it's a spatially-represented distributed publish/subscribe model. Maybe it is adaptable to your purpose.
Another thing that is probably immediately useful if you are most interested in file synchronisation -- librsync. It implements the rsync delta algorithm, by the looks.
Related
I struggle with the licence of the software I wrote in C(the core) and C++(the GUI).
At the beginning I thought I'd use some crypto algorithm, but it was very easy to read the password stored inside the executable.
So to prevent hacks I decided to store all the valid serials inside the executable, my optimistic guess was there would be 1000 serials. No need to encrypt anything. But I read that it is possible to edit the executable, this means that if I write:
if(tb->is_demo)
{
//check limits
}
Somebody can by-pass it and write:
if(false)
{
//check limits
}
So, it becomes hard to protect my software, each solution that comes to mind, earlier or later there is a main if somewhere that can be bypassed.
The question are two:
Is possible edit an executable?
If yes, what can I do to avoid to get edited?
is possible edit a executable?
Without surprises, Yes.
if yes, what can I do to avoid to get edited?
You cannot completely avoid it. Big software development firms are working on the subject, yet their softwares (Professional software, games, ...) are hacked and used for free anyway.
What you can do is make the hack more expensive than your licence cost. You also can accept being "frauded". Or you can protect yourself by other means that technological ones (think law suits).
You may ask how to "make the hack more expensive than your licence cost?". This is off-topic on Stackoverflow. But be sure libraries answering that need exist. Now is the time to make your google skills pay ;)
Anyone can easily edit your executable so I would advise not to store all the valid serials in your program.
You could look into this open source project Open license manager
Another option is to store all your valid serials in a database on some server and create an API that you can make requests to whenever you want to check if a serial is valid or not.
You could use python and flask to create the API and the server
Yes, an executable can be edited. Many software have been cracked through this method. There are however two ways of doing this:
Hash editing
Through third-party software
It is possible to "avoid" them. You can either encrypt these files or you can lock the data from being streamed out.
I have a similar problem with this. How to program a simple CANopen layer .
I read the answers but I have to program a CANopen layer on my own I cannot get a commercial one. So are there any basics of writing a CANopen stack (or layer I'm not certain about the difference)? I don't know even where to start..
If it's required here's some information :
My master device is a beagle bone black with QNX. QNX has a generic CAN library I think but not specific to CANopen. And my slave is a militarized brushless motor controller. I'm writing in C++.
I have a documentation about the general requirements of my system.
There are 2 RPDOs and 4 TPDOs, transmission is synchronous, there is no stopped mode( so no heart-beat and node guarding) and all message informations are stated (size, format, related node IDs etc.)
There are actually at least 4 open source projects that implement CANopen:
CanFestival is the oldest and might be the most mature solution. License: LGPLv2.
CANopenNode is aimed at micro-controllers. License: GPLv2.
Lely CANopen is a library for implementing CANopen masters and slaves. License: Apache version 2.
openCANopen is a master that runs on Linux. License: ISC. Note: I am the author of this project.
I would have posted links, but apparently I don't have enough "reputation".
openCANopen also includes some utilities such as a daemon for forwarding traffic over TCP and a program that interprets and dumps CANopen traffic to standard output.
Lely CANopen is actually of pretty decent code quality and I might have used it if it'd been available when I started writing my own implementation. However, I have not tried using it, so I can't really say which implementation is "better". I can only say that they are different and one or the other may suit your needs better.
Now, I doubt that any of those implementations will work straight out of the box on QNX. They will either have to be adapted or you can copy individual parts of the code into your own implementations. At least that should save you some time.
The quick and dirty work-around is to only implement the bare minimum (just don't market it as CANopen or claim CANopen compliance):
Support for those specific RPDOs/TPDOs that the other node will send/expect to receive. Use fixed COBID (CAN identifiers). Forget about PDO mapping and PDO configuration, use fixed settings.
Implement a NMT bootup message.
Implement NMT state transitions between pre-operational and operational (your node needs to respond to these from the NMT master).
Implement some means to set the node id. Easiest might be to hard code it as a program constant.
If you are lucky, this is all that is needed. If you are unlucky, there will be SDO commmunication, meaning you will have to implement the SDO protcol and also the whole Object Dictionary. Otherwise, the above is fairly straight-forward and not that much work.
In case you need the Object Dictionary, then there might be no other way around getting a full-blown protocol stack. You'll also need to apply for a vendor id from CAN-in-Automation, but it's a one-time fee (no royalties).
I'm from Embedded Office and want to add my penny to your search, even if it's late. First I want to mention, the reason why we didn't put drivers into the canopen-stack repository is the complexity of embedded software development on multiple targets with multiple compilers and my goal to provide running software wherever possible. With just a library is hard to identify problems during usage.
The good news, I setup an environment to get the different targets and compilers managable by a single maintainer (me). So the canopen-stack is developped with LLVM on host machines, and a first demo is provided for STM32F7xx microcontrollers. More is coming, so stay tuned :-)
I am writing a piece of software in C++ which is targeted at a market in which software is traditionally heavily cracked (or at least, attempted to be). I realise that nothing can be completely protected, however I feel that trying would be a good idea and also I think some of the specifics of the situation that I'm in might be helpful.
Firstly, it would not be annoying to the user that they must have an internet connection to use the software. I hate it when games etc. do this too, but the software requires an internet connection to function anyway due to its purpose, so this wouldn't hinder a normal user.
Secondly, it depends fairly heavily on external scripts written by me and/or supplied by third-parties, so I can have these stored on some website somewhere meaning that people who crack the software will have to also track down new copies of the scripts, which may annoy them into becoming legit.
Thirdly, new versions will, by definition due to what the app does, have to be released very often, weekly or every two weeks max. The program will obviously have an autoupdater, but since I am churning out (required to function) updates so often, any sort of key-based encryption or whatever could possibly have the keys/method change every update, and I am capable of breaking existing cracks when they do happen.
Does anyone know of any available solutions or techniques I could implement which fit the bill?
If you application is doing some sort of data processing or analysis, you can protect it by putting that part into a web service (maybe in a cloud) that your client application connects and authenticate to and then receive results from. So even if your client application is reversed engineered, it would be missing that important piece of processing.
If your application is web based, you get the same effect too.
I've previously used CrypKey successfully.
I'm going to guess that older copies of the software are far less useful than the latest copy.
If that's the case, then you already have a powerful anti-cracker technology in place: your update mechanism. When you become aware of a hacked version of your software, then you can immediately check for it, and cause trouble for users of the hacked software.
I have never written any IPC C++ on Linux before.
My problem is that I will have multiple clients (writers), and a single server (reader). All of these will be on the same machine. The writers will deliver chunks of data (a string/struct) to the reader. The reader will then read them in FIFO and do something with them.
The types of IPC on Linux are either Pipes or Sockets/Message Queues as far as I can tell.
I was just wondering if someone could recommend me a path to go down. I'm leaning towards sockets, but I have no real basis for that. Is there anything I should read/understand before embarking on this journey?
Thanks
The main issue you should consider is what kind of data you are passing as this will in part determine your options. This comes down to whether your data is bounded or not. If it isn't bounded then something stream oriented like FIFOs or sockets are appropriate; if it is then you might make better use of of things like MQs or shared memory. Since you mention both strings and structs it is hard to say what is appropriate in your case, though if your strings are bounded within some reasonable maximum you can use anything with some minor fiddling.
The second is speed. There is never a completely correct answer for this but generally it goes something like: shared memory, MQs, FiFOs, domain sockets, network sockets.
The third is ease of use. Shared memory is the biggest PITA since you have to handle your own synchronization. Pipes are easy so long as your message lengths stay below PIPE_BUF size. The OS handles most of your headaches with MQs. Sockets are easy enough but you have the setup boilerplate.
Lastly several of the IPC mechanisms have both POSIX and SYSV variants. Generally POSIX is the way to go unless the SYSV type has some feature you really need or want.
EDIT: Count0's answer reminded me that you might be interested in something more abstract and higher level. In addition to ACE you can look at Poco. And, of course, no SO answer is complete if it doesn't mention Boost somewhere.
System V IPC is somewhat fiddly to use but it is a mature, robust technology. Message queues would probably do what you want and support atomic queuing/de-queuing.
Sockets are easy to use and also support communication over a network. However, they do not do any queuing, so you would have to write the queue management code within your server. Using sockets with C++ is not vastly different to using them with C. There are plenty of guides to this on the net and books such as Stevens' 'Unix Network Programming (vol 1)' that cover this topic in some depth.
A good place to get your feet wet is this sockets tutorial.
You'll then need to bone-up on threads & mutexes and here.
With the above you're all set to start playing ;-)
Though you've not asked for books, and because the answers above are so good, I'm only going to suggest you get your hands on copies of these two tomes:
UNIX Network Programming, Volume 2, Second Edition: Interprocess Communications, W. Richard Stevens
Advanced Programming in the UNIX Environment, Second Edition, W. Richard Stevens and Stephen A. Rago
There are inevitable ins & outs with this kind of coding, these two books will help you through whatever confusion you encounter.
Try to take a look at ACE (Adaptive Communication Environment). The ACE libraries are free available, very mature and cross platform. Unfortunately a good documentation is not, i would recommend this book to look for a good solution. You might try to take a look at this tutorial to get a feel of the patterns (at the end of the document). ACE uses a bunch of patterns to deal very successfully and efficient with those problems especially in a networked context, so it should be a good start to scope for good patterns and methods to use.
Especially Ace_Task using the Message_Queue allow to do what you need.
I have three legacy applications that share a lot of source code and data. Multiple instances of each of these applications be executed by a user at any time, e.g. a dozen mixed application executions can be active at a time. These applications currently communicate through shared memory and messaging techniques so that they can maintain common cursor positioning, etc. The applications are written primarily in C++, use Qt and run in total to about 5 million lines of code. Only some of the existing code is threadsafe.
I want to consolidate these three executables into a single executable and use multi-threading functionality to allow multiple instance of each of the three functionality branches to execute at the same time. It has been suggested that I look into some of the features provided by Boost, e.g. shared pointers, and use OpenMP to orchestrate overall execution of the multiple threads.
Any comments on how to proceed will be appreciated, particularly references on the best way to tackle this kind of a refactoring problem.
My suggestion to you would be design the desired solution first (firstly assuming that the requirements are the same) and then build a phased migration path from the existing code base basing it on the requirements that third party functionality may introduce.
Refactoring should be one small step at a time - but knowing where you are going.
The Working Effectively with Legacy Code (Robert C. Martin Series) will be a good read I'd suggest.
Trust me (I've got the t shirts) don't attempt to refactor unless you know how to prove functionality - automated verification tests will be your saviour.
I don't think anyone will be able to give you an informed answer. There are too many things to take into considerations. Only after careful analysis of the processes involved and the code behind would anyone (you included) be able to provide you with a project path.
That said, there are however a few things you should take into consideration.
Your applications and the way they seem to communicate with each other seems to me an already sound solution. This is so, especially because you have 5 million lines of code to tackle with, if you choose to get into refactoring your current system. This is a strong deterrent. If there is a need to provide threading support in order to optimize current application messaging, I'd perhaps suggest you consider the possibility of introducing MT into the shared memory and messaging routines, instead of merging applications.
The act of merging your applications could be seen at first glance as the "simple" act of gluing your current code and removing the current routines responsible for memory sharing and messaging, replacing them with normal function calls to the glued objects. My gut tells me it will not be that simple. You have to consider that almost certainly your current backbone code was designed for the current messaging solution. Your current abstractions were thought of with this in mind. You will almost certainly find that you will also need to make significant changes to existing backbone code. And again here you will find that wall of 5 million lines a huge problem. Because changes will quickly propagate across your entire system and leave you with 5 million lines of code to handle and god knows how many new bugs.
I'd suggest 1 above. But it may be that you do need for some reason to consolidate your applications. That being so, I'd still suggest something else before you try 2. Create an interface application responsible for firing up, displaying and maintaining the current 3 applications. Your users will know no better if you do this right. You'll still be able to apply 1 to your current system and join your applications under a common interface, despite them being in fact separate entities.
"...about 5 million lines of code..." Hmm... It is hard to say for sure without knowing your system, but since it is a "legacy" system, you can probably gain a lot by removing code duplication. Check out Simian and CPD.
5 million lines is a lot ot code. Of course, you may need it, but my guess is that you don't.
You definitely need a good reason to change a change a code-base like that to be multi-threaded, especially in C++. Doing it without cleaning it up completely first is a recipe for disaster.