Websocket how? - page 23
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
So you express how you would like to be able to enjoy the process yourself. Just understand: the server cannot be asked for a specific candlestick, only a range of candlesticks for selected dates. So think in that direction.
Then it would be better to write the data to a file. I don't understand how to add a folder
is it possible to intervene ?
Does nobody want to do a class/interface on the MT side beforehand ?
i.e. give a specific ToR that is discussed and enforceable.
let's get started:
class Hibou {
Hidou(string url=HIBOU_WS_URL); // думаю почти бесспорно
~Hibou();
void DoEvent(); // веб-сокеты асинхронны, а может в тредах реализуем, будем дёргать при первой возможности
int State(); // некое текущее состояние
/// хенды по событиям протокола, вызываемые из DoEvevnt
virtual void OnConnect(); // соеденились - зашибись
virtual void OnMessage(string json); // получили внятный Event
/// и так далее - заказчик представляет как он намерен использовать интерфейс.
/// если он этого не знает, мы за него ничего придумать не можем, клиника в руках пациентов
}
Not can ! YOU HAVE TO DO IT! The more interested parties get involved, the better!
Usually On[Event|Connect|Message] and so on are used to notify that the event occurred, but we don't have the ability to notify MT, such an event model unfortunately does not exist, we can not pass messages to MT((((
So we are left with only a method of periodic polling of sharp by mql, e.g. by a minuscule timer. (((
And for everything to happen correctly... Everyone who's read mql help has many times noticed the expression "events are queued", and the developers, including Renat, tell us at every step that all of the terminal events are synchronous and are processed in queue order, and all system and terminal events are placed in this very queue and processed sequentially. This is the reason why in the first edition I suggested using the same exchange mechanism: the queue.
Connect the WebSocket4Net library from Nuget packages to our project.
Describe the socket class. Add to it the IsOpen property, which will be responsible for the fact that the socket is open.
Literally lightly formalize the socket class, we write the necessary information through the context hints.
Next, we refine the global manager. In its static constructor we will immediately create an instance of the socket, so as not to forget about it.
I listened to Maxim and added to the global manager the method of connection to a specific broker. It will be convenient in case of development for other brokers.
We are refining the web-socket and creating event handlers for the socket itself.
I have listened to Maxim and added a broker-specific connection method to the global manager. It will be convenient if there will be development for other brokers
you must have been listening with your third eye :-)
you must have been listening with your third eye :-)
Max, you suggested creating a class, but we have GlobalManager class for general methods and I don't see any sense in creating a separate specific class.
As for the interface to MT, we will have the ConnectorMQL class, when we will test all our methods in the console mode.
If I've got something wrong, please correct me, try to make your point a little differently, don't make hasty conclusions.
P.S. Of course, you can make not only a universal entry point like ConnectorMQL, but actually a separate class HuobiMQL, which will send specialized commands to the global manager.Something I can't see
I can't see it.
It seems fine, it's not underlined. But you should put a semicolon at the end of the line.
I added a Points folder and made a HuobiMQL class in it
In the events of opening and closing a socket, I added setting the socket state property
Max, you suggested creating a class, but we have GlobalManager class for general methods, and I don't see any sense in creating a separate specific class yet.
As for interface with MT, we will have ConnectorMQL class later, when we will test all our methods in console mode.
If I've got something wrong, correct me, try to make your point a little differently, don't jump to conclusions.
On the design side: it's much simpler - @Fedor Arkhipov(author of topic and author of initiative) declares "I want it to be like this, but right now I need Hibou". And small/agreed corrections from us poor people :-) Because he is the one who knows what the whole idea is about.
I for one am not clear on the meaning of many classes, but that's my gripes...
You need to get the thing in the most compact form - you got an intelligible answer and a nice flow, and you solved the bugs. You can have hundreds of hierarchies of classes and methods :-)