paritytrading / parity Goto Github PK

When a cancel request is sent for an order that becomes filled before the order can be cancelled, the sequence should look as follows (source):

• Cancel Request (ClOrdID, OrigOrdID)
• Cancel Reject (ClOrdID, OrigOrdID)
• Execution(OrigOrdID)

However, while testing with my own application, I see an execution report with ClOrdID set to the cancel request ID, which seems wrong.

User name in session.java in method loginRequest is retrieved as 3978993080922546208.

But my actual user name in conf file is parity.

How do we retrieve use name

It should be possible to specify a network interface for each of the trading system's interfaces: market data, trade reporting, and order entry.

Only one stock ticker process listening to a particular session can be running on a host at a time. This is caused by a limitation in Nassau, the MoldUDP64 implementation used by the stock ticker.

Both the matching engine and the order book reconstruction could offer a method for storing auxliary order information (e.g. additional order identifiers).

Reference code
long orderNumber = nextOrderNumber++;

Order Number always starts with 1 and in case of Database persistence, it conflicts with previous order numbers. Order Number should be a randomly generated unique number or may be attached to currennt system milisecond to make it always unique

What I propose is:

    Random random = new Random(System.nanoTime());

    long orderNumber = random.nextInt(1000000000);

Hi, I have compile this project via maven. Because I'm newbie in trading apps, I don't know how to use this setting in config. In example in parity system.

market-data {
session = parity
multicast-interface = 127.0.0.1
multicast-group = 224.0.0.1
multicast-port = 5000
request-address = 127.0.0.1
request-port = 5001
}

market-report {
session = parity
multicast-interface = 127.0.0.1
multicast-group = 224.0.0.1
multicast-port = 6000
request-address = 127.0.0.1
request-port = 6001
}

order-entry {
address = 127.0.0.1
port = 4000
}

instruments = [
AAPL,
ETH-BTC,
EUR-USD,
]

Where I can get the market data setting ? Should I have some api from market data ?

Any advice appreciate

Matched order is not removed from Orders collection in ME's Order book com.paritytrading.parity.match.OrderBook#orders. As a result, it consumes RAM infinitely. The only way to remove an order from orders collection is to call cancel method after full order match (an order with remaining quantity 0). Also, fully matched order can't be republished to ME. Test to reproduce this bug attached. Hope to see fixed version soon.

com/paritytrading/parity/match/OrderBookTest.java

   @Test
    public void buyRepublish() {
        book.enter(1, Side.SELL, 1000, 100);
        book.enter(2, Side.BUY,  1000, 100);
      //        book.cancel(1,0);//  <- workaround to force clear of Orders collection after Match event
        book.enter(1, Side.SELL, 1000, 100);
        Event ask   = new Add(1, Side.SELL, 1000, 100);
        Event match = new Match(1, 2, Side.BUY, 1000, 100, 0);
        Event ask2   = new Add(1, Side.SELL, 1000, 100);
        assertEquals(asList(ask, match, ask2), events.collect()); // <- expected behavior
    }

Parity FIX Gateway is currently lacking FIX 4.4 session-level tests. Those should be implemented.

The current trade method in MarketReporter have following signature

long restingOrderNumber, long incomingOrderNumber,
long quantity, long matchNumber

TradeExecutionPrice is mandatory for the trade reporting purpose?
Can we have a hotfix in parity .8

I propose following changes in MarketingRpeorting

public void trade(long price, long restingOrderNumber, long incomingOrderNumber,
        long quantity, long matchNumber) {

and following changes in MatchingEngine in match method inside EventHandler

 marketReporting.trade(price, restingOrderNumber, incomingOrderNumber, executedQuantity, matchNumber);

The default parity-ticker output looks as follows:

09:37:57.088 BTC-USD    4619.38      14478   4619.39       5121   4619.39        131

The format makes it difficult to:

• Notice when a trade happens because last price is repeated all the time.
• Easily see which side of the order book changed (price and size) and how it changed.

The TAQ format (enabled with -t command line option) is better, but it could perhaps use color or something to make it even more readable for humans.

Now that market participants have to identify themselves upon logging into the trading system, an authentication and authorization mechanism can be implemented.

Parity related projects will be more useful if you strip the components into libraries and publish on maven.

Bug is find in function cancel in class OrderBook:

public void cancel(long orderId, long size) {
        Order order = orders.get(orderId);
        if (order == null)
            return;

        long remainingQuantity = order.getRemainingQuantity();

        if (size >= remainingQuantity)
            return;

        if (size > 0) {
            order.resize(size);
        } else {
            delete(order);

            orders.remove(orderId);
        }

        listener.cancel(orderId, remainingQuantity - size, size);
    }

Because remainingQuantity in Order get from Long2ObjectOpenHashMap<Order> orders difference with Order get from Long2ObjectRBTreeMap<PriceLevel> bids or Long2ObjectRBTreeMap<PriceLevel> asks. Then, value return canceledQuantity = remainingQuantity - size is wrong.

The data type for prices in PMD, PMR and POE is a 32-bit unsigned integer with a six-digit integral part and a four-digit fractional part. This accuracy is not enough for foreign exchange instruments, including Bitcoin-related instruments.

To accommodate foreign exchange instruments, the number of digits in the fractional part should be made configurable. Furthermore, the data type for prices could be changed to a 64-bit unsigned integer.

The command prompt of the terminal client should support tab completion.

MarketReporter.java in orderEntered method is showing incorrect price in
orderEntered.price = price;

For a price of 100, its printing 10000 with 2 leading Zero

However ticket is showing the correct price

Does it require some unpack?

  System.out.println(ASCII.unpackLong(side) +  " Order: " + orderNumber + 
    		" Entered by: " + ASCII.unpackLong(username) + 
    		" for symbol " + ASCII.unpackLong(instrument) +
    		" at Price " + price + " for Quantity " + quantity);

i just wanna ask. can this linked with our coins. example we have our coins and own trade...

then how to do this?

sorry new~im just can made blockchain not trade part.

Besides FIFO matching there are various algorithms used on different exchanges. For example "pro-rata" i.e. every order on a best level is filled according to it's relative size vs total size. I.e. if there are two orders for 2500 lots and 500 lots on a level a fill of 100 lots would be allocated as (100_5/6) for a first order and (100_1/6) for a second order. Reminder is typically filled at FIFO.

Anyway, there are a lot of rules out there, would be great to have an abstract interface that fills best level.

For eg. if quantity is like 0.1 , system floors it to 0.00 and hence rejects the order.
If quantity is like 1.02 , system floors it to 1.00 and accepts order with value 1.00
Is there any way to speciify precision for quantity value?

Just checking if all the applications and framework are in memory that data will not be persisted across restart.

Hi,
First thank you for this wonderful work, i'm trying out your library but i have two questions :

1 - Does this library use some persistence mechanisms such as if there is an outage, the orderbook is not lost or is it something that the developer should handle himself? if so what would you recommend ?

2 - And the second question is about scalability, can this orderbook works in a clustered setup ?

Thank you !

Market participants should be able to enter orders using HTTP.

Hi not very familiar with fix and other finance protocol. I have couple questions:

1. How can I feed orders, and get the published result out the system what basically client and reporter is doing ? In my use case I have to write a process to get them from db and persist the published results back into db.
2. Wonder why you have different multicast ports and how to retrieve data from each request port? Is there any architecture diagram that could explain all the communication flow better?
3. Whats the use case for using fix server here?

Hi, great project by the way, so i have question how can i use database to store the order book? because the order book is save on memory, right?

Would be great to have abstract interface which user could code into to create arbitrary market data out protocol (MDP)

The trading system should generate trade reports.

http://www.cmegroup.com/confluence/display/EPICSANDBOX/Implied+Orders

In derivative (and some other i.e. swaps) exchanges there is a concept of implied orders / matching. It's sort of an automatic arbitrage between related contracts (typically of different expiry + spread).

Non trivial to implement but important for trading something other than equity / FX.

There should be a way to obtain CSV or TSV output from the stock ticker. Such data could be easily plotted with R, for example.

POE, Parity's native order entry protocol, uses NASDAQ SoupBinTCP 3.00 underneath. One of the purposes of using it as a transport protocol is that it makes it possible for one market participant to maintain multiple concurrent order entry sessions with the trading system. This is, however, not yet supported by Parity itself.

Parity should support multiple concurrent order entry sessions per market participant.

Would be great to be able to replay recorded market data with particular speedup factor i.e. X1 - realtime, X5 - time time faster vs realtime, etc.

Market data should interact with user orders in a correct way. The tricky part is - for example replayed order for 200shs was executed against user order partially and 100shs remaining. Then market data can show that this order was increased to 300shs but in reality we may want to assume that order would have a size of 200shs (100shs consumed by user).

When a cancel request is sent for an order that becomes filled before the order can be cancelled, the sequence should look as follows (source):

• Cancel Request (ClOrdID, OrigOrdID)
• Cancel Reject (ClOrdID, OrigOrdID)
• Execution(OrigOrdID)

However, while testing with my own application, I see an execution report with ClOrdID set to the cancel request ID and ExecType set to Trade, which seems wrong.

While it is possible to implement market surveillance functions based on the market data feed, the trading system does not currently expose the originator of an order and, thus, it is not possible to attribute alerts to market participants.

The trading system should expose the originator of an order in similar fashion as it already exposes the counterparties of a trade.

The addition of cancel reporting (#49) introduced a fault to the trading system that results in trading system failure when an order is canceled on market participant disconnection.

Any Graphical User Interface ( GUI) to make things a little easier would fantastic

Market participants should be able to enter orders using the FIX protocol.

Matchnumber in MatchingEngine always starts with 1 and in case of engine restart it will have issues with duplicate matchnumber

We should have a random number generated based on miliseconds instead of an incremental number

Both Parity Trading System and Parity FIX Gateway should implement logging to help with setting up and debugging. The bare minimum would be to log the configuration at the startup.

Does it offers any kind of encryption for send orders?

TERMINAL CLIENT EXAMPLE.CONF

order-entry {
address = 127.0.0.1
port = 4000
username = parity
password = parity
}

instruments {
price-integer-digits = 1
size-integer-digits = 1

XRP-USD {
price-fraction-digits = 1
size-fraction-digits = 1
}
BCD-USD {
price-fraction-digits = 1
size-fraction-digits = 1
}
ETH-PROD {
price-fraction-digits = 1
size-fraction-digits = 1
}
}

**What we have ***
We have successfully able to connection between client and system.
Below is the code from TerminalClient.java(Parity-client)

TerminalClient.open(new InetSocketAddress(orderEntryAddress, orderEntryPort),
                orderEntryUsername, orderEntryPassword, instruments).run();

How can we close this connection?

Thanks

Having to navigate through multiple references can slow things down. Wondering if you are willing to try your https://github.com/ObjectLayout/ObjectLayout to speed up referencing where relevant and avoid object with data structure in object with data structure in object with data structure layout?

The terminal client uses JLine 2 for the command prompt. JLine 2 has been superseded by JLine 3, which is not backwards compatible with JLine 2. Upgrade the terminal client to use JLine 3.

I see an option to define this in terminal client only.
How do i set this in Trading Engine

An exchange needs an order entry protocol and a market data protocol. Most marketplaces have proprietary binary protocols.

Following the example, we could have an order entry protocol that is simplified from NASDAQ OUCH and a market data protocol that is simplified from NASDAQ ITCH. Furthermore, we could use SoupBinTCP as a transport for the order entry protocol and MoldUDP64 as a transport for the market data protocol.

Its working.
Please close ticket,

I have a web application deployed on Tomcat 8.5.29. The web application communicates with the Parity system, running on the same machine using Parity Client. This works perfectly fine on a local setup but fails on the cloud. I am getting a Broken Pipe Exception from the Parity Client.

sending data to parity server
Uhh ohh!!.. something went wrong !!
 after removing the bad connection--- null
java.io.IOException: Broken pipe
	at sun.nio.ch.FileDispatcherImpl.writev0(Native Method)
	at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51)
	at sun.nio.ch.IOUtil.write(IOUtil.java:148)
	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:504)
	at java.nio.channels.SocketChannel.write(SocketChannel.java:502)
	at com.paritytrading.nassau.soupbintcp.SoupBinTCPSession.send(SoupBinTCPSession.java:196)
	at com.paritytrading.nassau.soupbintcp.SoupBinTCPClient.send(SoupBinTCPClient.java:118)
	at com.paritytrading.parity.pojo.ColodaxOrderEntry.send(ColodaxOrderEntry.java:180)
	at com.paritytrading.parity.client.command.WebEnterCommand.execute(WebEnterCommand.java:57)
	at com.paritytrading.parity.client.command.WebEnterCommand.execute(WebEnterCommand.java:38)

Is there any configuration that I am missing?

Thanks for help in advance.

Can you add market maker to the book.