I doubt that many developers are using IEngine.broadcast, but I have
a specific need to send some messages which may be quicker than just
1 message per second.

Currently, IEngine.broadcast throws an exception if any broadcast
is within 1 second of a prior broadcast message. I am using this in order
to communicate between instances of Remote Live Server Strategy instances
so there isn't another mechanism available for me to use for inter-Strategy
communication within a single Account Login.

Unless this can be relaxed, then I will have to "bundle" multiple messages
into a single broadcast, which will greatly complicate my messaging design.
In that case I may have to "bundle" multiple messages into a single
broadcast.

In the exception below, a request was made 984 milliseconds after the prior
request, so the exception is thrown.

com.dukascopy.api.JFException: Broadcast min period exceeded : 984 / 1000
   at com.dukascopy.api.impl.connect.JForexEngineImpl.broadcast(JForexEngineImpl.java:429)

What other undocumented restrictions are on IEngine.broadcast. What is the maximum
size of the topic and message strings?

Ideally, I would prefer that there not be a "throttling" restriction, but I realize you have designed
in the "throttling" to protect the server.

So I would prefer if I would be able to broadcast perhaps 4-5 messages per second in "bursts", although that would not be a sustained rate, and I won't be abusing the feature.

Thanks very much for considering this request.

HyperScalper

I've developed a "batching" and throttling bi-directional asynchronous "message bus" which does
the job very well. It would still be a good thing if the minimum required inter-broadcast
delay could be lowered maybe to 500 msec or less for a slightly higher
broadcast rate, from the current 1000 msec.

Thanks,
HyperScalper

If by "batching" you allude to the aggregating of raised messages occurring within the 1 second window into a digest or digests sent out together then I commend your approach

This is a good work around while waiting for the JForex team to reduce the built-in latency.

In fact it's a very good general approach in spite of the eventual latency improvement.

Yes, there is the possibility of multiple message "batching", destined for
a single broadcast call. Just a Queueing mechanism with the required
"pacing" and "message packing" in the same threaded facility.

This facility can send and receive asynchronously.

As for latency, beyond the 1 second repeat broadcast mandatory delay,
the single broadcast latency itself is fairly quick.

I see a round-trip broadcast to Server, and response broadcast back to
me trapped in onMessage on the server side, (a "ping" if you will),
in about 250 milliseconds.

This is entirely adequate for the control I need over a collection of
Remotely executing Strategy modules. Thus I have control over all
Strategy parameters, even though they are running on the Remote
Server.

Remote Strategy modules can also send "log" messages back
to a Console, which are intercepted when the console is actually
running. Otherwise, the Strategy modules just continue running
and could log data locally, I suppose, to be forwarded later
depending upon their importance.

HyperScalper

Broadcast topic max length:100 symbols.
Broadcast message max length: 1000 symbols.
Broadcast message sending min interval: 1000 milliseconds.

We cannot change a broadcast min interval because of a possible overload of our trading servers.

Thank you for documenting the restrictions.

I wonder... who makes these decisions? I can live within these restrictions,
but to whom would I appeal if I really needed a change?

HyperScalper

API Support group makes these decisions.