Would anyone know how to do the bi-directional connection between Java and MQL5? Preferably using ZeroMQ.
In that case Java would receive data (probably arrays) from MQL5, it will compute and return information to MQL5. This all at runtime.
Here is an example of helloworld from MQL client (it is possible to use MQL as server but it is rather difficult to imagine why someone may need that) at github. Java server example is at the official page.
You may use json to exchange messages (ydrol or sergeev lib is to help you, keep in mind the latter may have issues with parsing arrays) or choose some other format.
Probably the easiest is to pass ticks or m1 candles to java using json, then receive trading commands to MQL.
Related
I need to implement rather simple network protocol: there is device with microcontroller (language is C) and Java application, they should communicate: I need to implement firmware update, and maybe some other things.
At least, I need to transmit some data structures as headers.
Only ugly way comes to mind:
I can declare packed structure on C side, and handle somehow the same data flow on Java side.
So, if my structure is changed, then I need to make changes on both sides: C and Java. I strongly dislike this.
Is there some better way to do that? Maybe, something like this: I should write protocol structures in some special format, and then some utility can generate code for C and Java sides.
Or, maybe, something different.
I would be glad to see suggestions.
You might want to look at using a standardized notation for data transfer such as JSON. Here is some info on parsing JSON in c.
Parsing JSON using C
If it were my project I probably would go with just packed data structures. Hopefully once your project matures changes to the data structures are minimal and only occur during major releases. You can keep a version tag in the data structure to handle legacy data formats if needed.
One common solution to this problem would be to use Google's protobuf. However, as you
specified that you need it to work in a microcontroller environment I think you could look
into protobuf-c, which is a pure C-version of protobuf.
Could you describe details of protocol? Is if statefull or stateless?
If your protocol is stateless, then take a look at web-services (especially, REST-WS). This is well known cross-platform communication practice.
I want some help on a way to transfer data from a python web application to a java desktop application.
What I am doing is having java listen on a port and receive data. But I have no idea how I would send data from python to an open port on a server.
What my question is how would I send data from a python web app to an open port on a computer. And would there be any problems like data types and any other things?
This is a really large question as there are many ways to send data back and forth between server (your java app) and client (your python app).
Your situation is not quite clear (what exactly is your "python web application"?), but you may want to look into XML-RPC. XML-RPC is extremely simple to use and set up, and takes care of "problems like data types and any other things". You basically just set up some functions on your server that the client can call, and have python call them. Arguments are neatly wrapped up by teh client and unwrapped by the server. Return values are the same. It is a simple and clean interface.
For python making calls to the server, you want to use the xmlrpclib module.
To set up an XMLRPC server in java, you have many options. I'm not a Java guy, but I'm sure it is quite simple on that side as well.
There are many good xml-rpc tutorials. Here is one that covers client and server in python.
Like I said earlier, there are MANY options available to you. XML-RPC is a good and simple way to get your feet wet, without really limiting you very much (eg: it has built in fault handling).
Good luck!
If you use a platform independent data format -- xml, json, yaml, ascii txt, ... -- to represent numbers, you have really nothing to worry about.
If you can not afford the inefficiencies of above, then a binary protocol is required.
Java uses network byte ordering (or Big Endian). Python uses the native host byte ordering, OR, you can specify the byte ordering. Here you want to specify Big Endian (sec 7.3.2.1) in writing your numeric data.
Why not use sockets in python too and send it to the java server. Java does not know that the end client is python, what it reads is just data(bytes). I have done this, and it works seamlessly.
See the python's struct module for more details on converting datatypes
I am writing a client server iPhone app. The server is J2EE based.
I need to communicate the state of my client object (objective C) to the server. It is possible (and feasible) to say encode the objective C object, send the bytes to the J2EE server through a socket and create a Java object out of this stream. If so, can you kindly point me to a starting point.
Thanks in advance
Anything is possible, but that does not make it feasible. Except the technical difficulties these interfaces tend over time to create a lot of management headaches, example when one or both sides perform an upgrade.
I would seriously consider using some encoding to some platform neutral format like protobuf, thrift, JSON, XML or similar.
It sounds like it would be easier to serialize the Objective-C object to XML, JSON, or another text-based representation and ingest and unmarshal that in Java. To return it, reverse the process.
There are myriad ways to skin this cat. If you are using J2EE, you might even consider using a standard means of communication rather than rolling your own. For example, you could use a webservice, REST, etc. Objectice-C has good support for HTTP connections and it is fairly trivial to create an XML or JSON payload. SudzC is a great tool for creating a client proxy from WSDL.
Here are a few tools on the Objective-C side:
json-framework
SudzC
What are possible options to transfer a lot of data from one computer to another not in the same LAN. The amount of data is about 100Mb unzipped and 2Mb zipped? Another requirement is that when I create a server for this (with C#) Java clients should be able to consume it.
Does WCF support something like this? But if Java clients won't be able to consume it I'm not interested.
What could be other strategies here?
I'd just use something common like HTTP or FTP, since there will be plenty of existing libraries to do it and you're pretty much guaranteed not to have compatibility problems. 2MB is not an unreasonably large amount of data for those protocols.
This is an interesting kind of question. The question is fairly simple to answer. But the interesting thing is that this kind of questions are new, they didn't exists before. Let me explain, but first I will answer your question:
You should create a server and clients both using old fashion TCP streams. To not waist bandwidth you need to compress the stream somehow, here use one of the most common compression algorithms you can find (anyone said Zip?). Now you have a language independent protocol. Clients in any language will work, mission accomplished. Also to keep it cross-platform, do not pick the best compression out there, pick the most common one (It will be good enough).
Now to why this kind of questions are interesting, they show something about OOP on the large scale. People understanding and using huge frameworks and asking if this or that framework can perform this or that simple task for them. Here we have lose our roots, we have lost the inner workings of things, it's hitting the nail not with a hammer but with a nuclear missile. It's overshooting the target, and it will produce huge applications, with huge footprint and often poor performance.
I believe that this questions has increased in number since OOP was fully adopted. It's like new programmers only want to learn these new big frameworks and that the framework dim the view of the world. There is absolutely nothing wrong with big frameworks, they are great, but I believe it's wrong to start out using them before one have mastered the basics. It's like learning to fly using a NASA space shuttle instead of a school version of a Cessna private airplane.
In C# you can serialize your object as an XML and transmit, on the other end your can deserialize your XML back to an object.
In terms of files size, you can transmit as zipped or 7z..and on the client decompress it before parsing the xml.
WCF supports SOAP and includes optional JSON serialization for XHTTP. There are other mechanisms but they are MS orientated. You will easily be able to consume the service you create. However you will have to consider how to encode the data as it will hit the wire in a non binary data friendly manner (XML/JSON).
You may wish to instead create a simple http handler that can return the data directly as zip using appropriate mime headers etc. You should then be able to just hit that using your Java client.
XMPP is another option. You need another server, but this could be an advantage: the client wouldn't need to know the servers IP address, server and clients would simply connect to the XMPP server to exchange message and files.
Related links (for Java):
Openfire XMPP server
XMPP library for java (Smack)
You didn't mentioned what type of data do you want to send. So for keeping things simple I will suppose that you have data stream which can be converted to byte array. Content of the stream has to be in format which is understandable to both C# and Java!
The best choice is to compress your data stream with GZip stream. Gzip should be supported on Java. Than you can send that stream converted to byte array as response from your WCF service operation. You can use default text encoding which will convert byte array into Base64 encoded string. If your java client supports MTOM (it is standard which is supported by Java) than you can use MTOM encoding which uses smaller messages.
If you don't have a stream with well known content format you have some sort of custom data. For custom data you have to use interoperable transport format which is XML. Using XML will futher increase size of your data. In that case you should consider dividing your data transfer into several calls. You can also try to host your WCF service in IIS 7.x and take advantage of its build in feature - compression of dynamic content. If your Java client calls the service with HTTP Accept-Encoding header set to compress, gzip it will automatically compress the response. Be aware that only .NET 4.0 WCF clients can work with such service.
I have to create a server(java) - client(c++) system, both server and client will have to work with objects (data types) wich are the same for the client and for the server, for example a car object will be created on the client side and then send to the server where aditional calculations will be done on the car object. What i would like to do is to create one universal implementation of the car object and than use this implementation within the server and the client. First i thought about creating a dll (in c++) with all data types wich are same for the client and the server, but this solution has a drawback. Because this solution only works under Windows OS and i have to support Win,Mac,Linux. So is there a multiplatform solution for my problem ?
I give my thanks to all your replyes.
Google has an Open Source library called Protocol Buffers for transferring data objects between clients and servers as in your situation. It support C++, Java and Python.
as well as protocol buffers, there is another one called thrift (facebook's protocol buffers). see http://incubator.apache.org/thrift/
see this page for a comparison http://stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers
Take a look at CORBA: http://en.wikipedia.org/wiki/CORBA
Provided you stick to standard libraries (cross platform), you shouldn't have any difficulty recompiling your library (DLL) as shared libraries (.so) on OS X and Linux. Of course, loading them in Java is a different issue (which I don't have any expertise in).
However, more importantly, in your case of a client server application, you probably want to look into effective serialization of your objects so that they can transmitted over the network and reliably reconstructed by the receiver.
This looks like a good job for XML. That's where I would start.