philadelphia-client: Add 'expect' command

[jvirtanen]

Philadelphia Terminal Client can run scripts nowadays. For testing FIX acceptors, an expect command would be useful. The syntax of the command could be similar to the syntax of the send command. For example:

expect 35=A|98=0|108=30

On the other hand, it should also be possible to skip the expectation for a specific field value, such as the OrderID(37) and ExecID(17) values here:

expect 35=8|37|11=1|17|150=0|39=0|55=AAPL|54=1|38=100|151=100|14=0|6=0.00

Like send, expect should expect the fields in the specified order.

An open question is how expect commands should match with incoming messages. Should the expect commands form a FIFO queue against the first of which an incoming message is matched? What should happen if an expectation fails?

[khsergvl]

@jvirtanen Will take care about that next days

[jvirtanen]

Great, @khsergvl! I think it makes sense to discuss here first the semantics of the expect command. What exactly should it do?

To get started, if you are not yet familiar with the terminal client, a good exercise is to the Parity FIX Gateway test script. You can do it as follows (assuming that Parity is in a parity directory next to the Philadelphia project directory):

1. Run Parity Trading System:

   java -jar ../parity/applications/system/parity-system.jar \
           ../parity/applications/system/etc/devel.conf
   

2. Run Parity FIX Gateway:

   java -jar ../parity/applications/fix/parity-fix.jar \
           ../parity/applications/fix/etc/devel.conf
   

3. Run Philadelphia Terminal Client:

   java -jar applications/client/philadelphia-client.jar \
           ../parity/applications/fix/test/test.conf \
           ../parity/applications/fix/test/test.txt
   

In principle, it would be great if this test script would some day use expect to automatically fail on unexpected incoming messages.

[khsergvl]

@jvirtanen Thank you for good example and assistance. I think that it's also sense to add index as it's in messages. In this way will be easier to handle test cases like messages - 2. What do you think about that?

[khsergvl]

@jvirtanen So, what do you think about my idea?

[jvirtanen]

@khsergvl I think the expect command should work like the wait command, not proceeding until the next message is received and then matching it against the expected message. The expect command should probably ignore at Heartbeat (0) and Test Request (1) messages as well as the same fields as messages currently ignores:

• SenderCompID(49)
• TargetCompID(56)
• MsgSeqNum(34)
• SendingTime(52)

[khsergvl]

@jvirtanen As i'm now working to implement this feature, what do you think if expect command will print to terminal client output in the matching case? I'm also propose to add special tag which mean, that we are want to skip until to some field in matching message. The value of this tag will point on the tag util we want to skip. What do you think about that? In any case i'm working on some prototype - so we could adjust that.

[jvirtanen]

I think for starters the mechanism suggested above, |37|, should be sufficient. It should check that the tag is correct but the value is not checked. Adding a special tag could be a bit troublesome as basically any integer can be a valid tag.

Regarding your question, yes, I think it would make sense to print the matching message upon reception. 👍

[khsergvl]

Hi @jvirtanen. I've done scratch for expect command, so could you have a look? Keep attention on failure during CI checks - is it all ok after your dependencies update?

[jvirtanen]

Hi @jvirtanen. I've done scratch for expect command, so could you have a look? Keep attention on failure during CI checks - is it all ok after your dependencies update?

Yeah, I noticed that yesterday. It looks like Travis is having some issues with their Java 8 support. 🤷‍♂

[jvirtanen]

Yeah, I noticed that yesterday. It looks like Travis is having some issues with their Java 8 support. 🤷‍♂

I switched from Oracle JDK 8 to OpenJDK 8 on Travis, and the Java 8 build works again.

[khsergvl]

@jvirtanen yeah, working fine now, thanks.