Hi

Moving away from MT4/MT5, I am new to JForex and JForex API For now, I have here 3 questions:

1) Can I establish a bi-directional socket channel between a standalone API custom Application (JForex SDK) and a remote run strategy(ies)?

2) Regrading remote run strategies, the documentation states the following:
"One may not use @RequiresFullAccess annotation, hence, in order to use external libraries, during the compilation he has to place them in the IContext.getFilesDir directory."

Is this a default location given by JForex platform itself? is this a location on the remote server?
But, how to put external jar files in IContext.getFilesDir directory?

3) Regrading speed of order execution and price feed delay, is it OK to use a standalone API Client for a strategy that operates on a 5 minute timeframe? Or, using remote run strategies is generally recommended? Please, advise.

Thanks!

No you cannot, however, you can use IEngine.broadcast to send messages between the remote and local strategies, see:
https://www.dukascopy.com/wiki/#Broadcast_message
The location can be set in platform - Tools -> Preferences -> Advanced -> Strategies path. The directory will be Strategies path/files. This is the location on your local computer - you simply move the necessary dependency jars to the directory when you compile the strategy on your local machine.
The two are not disjoint (for instance, you can run remote strategies from JForex-SDK), rather it is whether you use Local Run or Remote Run and if you use the platform or JForex-SDK. Straightforwardly the execution is faster and price delay is smaller due to the remote strategy server close proximity to our trading and price feed servers.

Thanks for explanation.

Now, considering running remote strategies from a JForex-SDK Client, and which is a client/server architecture solution, I am still not sure about how best to distribute business logic and responsibilities between client and server. Example for a possible architecture (if this makes sense):

Server
- Order execution (open, close or delete of pending orders).
- Risk/money management (trailing stops, lot sizing etc.)

Client
- Checking trading signals (and market conditions).
- Initiating order execution on server side (i.e. sending commands to server to open/close orders depending on
trading signals checked by client).
- starting remote server(s)
- stopping remote server(s)

On one side, if client triggers order execution on server side, we would lose the benefits of fast order execution with regard to communication latency between client and server, correct?

On the other side, if we put the entire trading and business logic on the server (remote strategy), responsibilities of client would be not more than starting or stopping server(s), just acting as a console (thin client).

What are best practices using a C/S architecture (local client / remote server(s)) ?

Normally the remote strategy is an independent entity and does not require interaction with the Client (i.e. JForex-SDK or platform). Thus you should put all of your trading logic within the strategy. The only reasonable case when you may want to communicate with the remote strategy is by passing to it some settings/parameters which would change its behaviour.
Yes, it does not make much sense to send the remote strategy trade signals as the trade is likely to be executed faster from a local strategy, because it also takes some time for the broadcast message to arrive to the remote strategy.
This is actually by the IClient interface design. Except that the console you get in the platform by selecting Portfolio -> Strategy Log.

I think it is a better approach if you think of your strategy as the client. It (the strategy) will 'ask' for order submission, order cancellation or order modification (trailing SL/TP).
The client is responsible to do the necessary calculations (check indicators, calculate SL/TP prices, etc), and when it is necessary it will inform (ask) the server to do it. And the actual order submission, modification, etc is of course taking place on the server.


Local/Remote:
The question is: where do you start and run your strategy (remember, the client)? Do you run it locally (on your PC), with all the features enabled. Or you run it remotely (on a Dukascopy server), with the advantage of less communication delay (latency), but with the disadvantage of not being able to use all features, as the remote environment is limited (for example, you can upload only a strategy, and cannot upload libraries that is used by the strategy).


Starting strategies:
When you have made the decision about Local vs. Remote, the question is how do you start the strategy? Do you start it using the JForex platform, or alternatively you start it by using the JForex-SDK.

This is not true, see the No. 5 here:
https://www.dukascopy.com/wiki/#Remote_Run

Ok, sorry for the misinformation.
And glad to see this new wiki-page!

Thanks API Support!

Regarding memory and processor load restrictions for remote strategies, so putting all of trading logic within the strategy would not be a problem?

Thanks for your feedback. Yep, this exactly what I stated in my post The server should focus on order tasks (open, close, modify, trailing stops etc.) in order to take advantage of the close proximity to trading and price feed servers. Client should manage the strategy itself, like checking trading signals, deciding on entries, exits etc.

Have you already implemented such approach? if yes, how have been the results so far?

Thanks

And what I tried to state in my reply , is that the server side is not something you should directly consider. Leave that to Dukascopy . When you develop a strategy that submits an order, you have done everything you should (and could) do.
Let's take an example, just to make it clear what I mean:
Consider a strategy that uses an indicator to decide when to place an order. When the condition is fulfilled, this strategy will submit an order by executing the engine.submitOrder() method.
This function will inform the server (automatically, without you actually doing anything on the server side), that an order submission should take place. If it is possible, an order will be filled (this is again done by the server).
Note the difference between order submission and order fill. The order is in the submitted state when a strategy submits it, but only get to the filled state when the server actually placed that order in the Forex market with the given parameters (amount, SL, TP, slippage, etc).

The same thing happens whenever you close, or modify an order: you call IOrder.close() in your strategy to call an order, and this function will inform the server to close that particular order. And the server will do what you have asked from the strategy: close the order.


Edit:
After reading your reply again, I must admit that now I am not sure if I understand your question .
Are you planning to run 2 strategies? One will take care of order execution, modification only (this is what you call the server), and the other will handle the indicator calculations, trailing SL calculations, etc, and if necessary inform the other strategy with the required actions (add order, modify order's TP/SL, close order). And this latter strategy is the client in your idea?

Sure, but I know very well about all these trading basics




Yep, this is correct, just the old-fashioned client-server model where trading/business logic and responsibilities are distributed between client and server (in different ways). Client commands (e.g. open/close order, delete Buy stop or limit order etc.) still need an efficient and secure communication channel to server(s).

Broadcast messages are certainly inappropriate to use for such critical trading commands/operations.

Well, I haven't tried these yet but I don't want to wipe out my account