Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Daniel Schonfeld
    @danielschonfeld
    Does the ticker example only show the current best bid and best offer? not the whole order book?
    Jussi Virtanen
    @jvirtanen
    Correct.
    Daniel Schonfeld
    @danielschonfeld
    thank you
    Daniel Schonfeld
    @danielschonfeld
    one more question
    if i'd like to update an order, to INCREASE the size... is the only way to do that is to cancel the current order and create a new one?
    otherwise CancelOrder is only for reduction or total cancellation ?
    Jussi Virtanen
    @jvirtanen
    Yes, that’s correct.
    Daniel Schonfeld
    @danielschonfeld
    is there a way to query the matching engine what the current qty for an order ID is ?
    or is that left up to me to save on my own and make that determination at a later date if i'd like to increase the qty
    Jussi Virtanen
    @jvirtanen
    It’s up to you to keep track of the orders. 🙂
    Daniel Schonfeld
    @danielschonfeld
    thanks @jvirtanen
    appreciate the quick responses
    Daniel Schonfeld
    @danielschonfeld
    @jvirtanen is there a requirement to send one message, then wait for a response/ack and only then send another message?
    because I am trying to send two messages in succession (delete, enter order) and it doesn't seem to be working so well
    Daniel Schonfeld
    @danielschonfeld
    nevermind, it seems to be working fine
    apologies
    newbielinuxuser
    @newbielinuxuser
    @danielschonfeld what programming language do you use to communicate with FIX protocol ?
    Nitesh Agarwal
    @nagarwa2
    @jvirtanen Is it possible that the client doesn't receive OrderAccepted command from Parity but OrderExecuted command ?
    Jussi Virtanen
    @jvirtanen
    No, Order Accepted will always precede a potential Order Executed.
    Daniel Schonfeld
    @danielschonfeld
    @jvirtanen is the only way to force a 'market' order, by setting the price of a buy to double MAX_VALUE and a sell order price to 0?
    Jussi Virtanen
    @jvirtanen
    There’s no market orders; setting a marketable price as you suggest gets you close but lacks the immediate-or-cancel characteristic of a market order in case of insufficient liquidity: the remaining quantity will be entered to the order book as a limit order.
    Also note that POE uses integer prices represented in terms of the minimum price increment.
    Zachary Broniszewski
    @zbroniszewski
    @jvirtanen To clarify, all orders entered into Parity are limit orders by nature, is that correct? So, in the case of a market or stop order, this will have to be handled by the overall application that connects to Parity. In my use case for a stop order, I simply have another instance of the order book within my application memory like Genesis, and use Observables to pay attention to the trade prices, and if the right trade price is hit according to the price of the stop order, this is when I am finally sending that stop order to Parity as a "market" order, whereby I am actually just pulling the last trade price at that exact moment for this. Does this sound like incorrect architecture? The only other possibility I would assume is that for example Coinbase' order book engine does take into account all types of orders, etc., and it doesn't have to necessarily be handled by the overall application. But, I think both methods should work fine. You would confirm that Parity as-is can be used for market, limit and stop orders if handled correctly by the backend, correct?
    Zachary Broniszewski
    @zbroniszewski
    @jvirtanen I am testing making some minor adjustments to Parity. Specifically I'd like to change the orderId length to 36 to support uuid version 4. By default, POE has an ORDER_ID_LENGTH of 16, MAX_INBOUND_MESSAGE_LENGTH of 42, MAX_OUTBOUND_MESSAGE_LENGTH of 58. I've increased all of these by 20 to account for the orderId length increase of 20 from 16 to 36. I've run mvn package from the project dir: parity-0.7.0. It does allow now to submit this new orderId length, however POE sends back the orderId cut off to 16 characters. Additionally, attempting to change PMR VERSION to 3 and then running mvn package, PMR sends back VERSION 2 still. This worked for PMD however, where it sends version 3 on connection. It seems as though my changes are not taking effect to PMR. I'm most concerned about getting POE to send back a 36 character-long orderId however.
    Zachary Broniszewski
    @zbroniszewski
    @jvirtanen Nevermind, disregard the above. However I would still like Parity to accept 32 or 36 character orderIds, would you happen to know if this solution is simple?
    Jussi Virtanen
    @jvirtanen
    @zbron99 Parity only supports limit orders. If you have a trading system implementing market and stop orders, what would you need Parity for? :smiley:
    Zachary Broniszewski
    @zbroniszewski
    @jvirtanen We simply resemble market and stop orders by managing when and at what price orders go into Parity. But I'm assuming you are suggesting that the orderbook engine itself should be the one to handle this?
    Jussi Virtanen
    @jvirtanen
    Well, kind of; why use Parity at all? Especially if you have implemented logic for market orders and stop orders, doesn’t speaking to an external matching engine for limit orders just increase complexity? (Especially as Parity is not really designed to be embedded.)
    Zachary Broniszewski
    @zbroniszewski
    @jvirtanen Understood, makes a lot of sense thanks! I am seeing what I can do to first implement market orders into the engine. I'm about to test. Seems fairly straightforward. Market orders should never be added to the order book, so in the buy or sell method of libraries/match/OrderBook.java, if the order is a market order, my implementation for now is to simply grab the price of the bestLevel, attempt to match that order at that price until the bestLevel is either null through each iteration, or it's price is greater than the price of the first bestLevel.getPrice() query (The decided price for that market order).
    Only gotchya is that I'll have to make a work around for a market order since a price will not be passed as a parameter into these buy and sell methods, since it's price won't be determined until within the scope of those methods.
    Jussi Virtanen
    @jvirtanen
    Remember that a market order has no price. Unless the order book is empty, it will result in one or more trades, each potentially occurring at a different price.
    Zachary Broniszewski
    @zbroniszewski
    @jvirtanen Is there any reason why the price of the best level at that exact time wouldn't suffice as the "order price" of that market order?
    So the order book engine decides the "limit price" of the market order based on the price of the best level at that exact time.
    Zachary Broniszewski
    @zbroniszewski
    On second thought, this is not correct, since market orders strive to be fulfilled completely, and if we use the price of the best level at the time the market order is submitted (as a "limit" price), it increases the chances the order isn't matched in full. So in that case, we should continue iterating through the best levels until the order is filled completely, and take an average of the prices that order was filled at quantity for quantity as the fill price?
    Or perhaps the fill price of a market order is the highest price paid during matching
    Zachary Broniszewski
    @zbroniszewski
    @jvirtanen Disregard, several hours later and Parity now supports market orders correctly ;)
    Zachary Broniszewski
    @zbroniszewski
    @jvirtanen in your opinion, would it not be architecturally sound to populate the order book based on a Redis file when the system first starts? What I am trying to do is ensure that on server/system restarts, the order book engine can repopulate any orders that existed before restart. I'm assuming all exchanges must have this implementation, they can't be relying on the instance of their order book engine to be active 24/7 right? If it is architecturally sound, this means I'll have to manage updating the orders and trades in redis. I'm in the process of identifying whether I'll have to do this from within the engine itself, or by responding to the order entry/market reporter messages from Play and Scala for example. I think it would make the most sense to do it from within engine itself. Your parity-ticker repo I'm assuming is designed to live in the parity-0.7.0/applications directory right? Still I think that updating a database, even if in memory, would cause issues if the mechanism for which is done by waiting for the order entry/market reporter messages to come through first. What are your thoughts?
    Vladyslav Ilchenko
    @Zenceras

    I have 2 questions:
    I. Can I somehow configure Nassau Gateway to run it as 1 JAR but allow simultaneously converting MoldUDP<->SoupBinTCP for Parity Reporter and Parity Ticker?
    Now I have this Nassau config for Parity Reporter(as Upstream I using "market-report {}"):

    upstream {
      multicast-interface = 127.0.0.1
      multicast-group     = 224.0.0.1
      multicast-port      = 6000
      request-address     = 127.0.0.1
      request-port        = 6001
    }
    downstream {
      address = 127.0.0.1
      port    = 7000
    }

    So can I somehow add as upstream this Market Data config:

    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
    }

    and expose it for Parity Ticker lets say on the port 7001 in the same Nassau JAR - or I must change package name to the second Nassau and run it as a separate JAR for conversion Market Data?

    II. The second question - as I understand Parity Ticker now send Bid1 and Ask1 prices(i.e. best Bid and Ask prices). I need to stream 5 prices for each Stock like this:
    Ask5
    Ask4
    Ask3
    Ask2
    Ask1
    Bid1
    Bid2
    Bid3
    Bid4
    Bid5
    What is the best way to solve this problem?

    Jussi Virtanen
    @jvirtanen
    @Zenceras Once instance of the gateway handles one MoldUDP session. Just run two instances of it with two different configuration files.
    The ticker does not send anything; it only receives. All price levels are already being sent on the PMD protocol level, and the ticker just displays the first price level.
    Vladyslav Ilchenko
    @Zenceras
    Thank you for your answer!
    Anirban
    @anirbangupta4_twitter
    Our company is planning to use Nassau software for getting price feeds from NASDAQ. As in the NASDAQ documentation, the price feeds are Multicasted over channel using MoldUDP64 protocol. Can you please say where can I find the documentation of Nassau or how to use it to get price feeds from NASDAQ?
    Anirban
    @anirbangupta4_twitter
    We would like to receive the intraday prices of stocks, we came across Nassau but am not getting how to use it.
    crowlogic
    @crowlogic
    @Zenceras I had the same question , did you discover anything more ?
    @anirbangupta4_twitter call nasdaq, http://www.nasdaqtrader.com/Trader.aspx?id=DPUSdata is a good start
    Jussi Virtanen
    @jvirtanen
    Hi @anirbangupta4_twitter! Note that Nasdaq uses MoldUDP64 as the underlying transport protocol and TotalView-ITCH 5.0 as the actual market data protocol. You need both in order to consume the market data from Nasdaq. The latter is implemented in Juncture.
    Here is a little example that uses Nassau and Juncture to read historical market data files from Nasdaq: https://github.com/jvirtanen/nasdaq-tools
    Vladyslav Ilchenko
    @Zenceras

    Hi, when I started to stress-testing my system I see this Exception from Parity System(before stress-testing all worked very good):

    Exception in thread "main" java.nio.BufferUnderflowException
        at java.base/java.nio.Buffer.nextGetIndex(Buffer.java:641)
        at java.base/java.nio.HeapByteBuffer.get(HeapByteBuffer.java:162)
        at com.paritytrading.parity.net.poe.POEServerParser.message(POEServerParser.java:35)
        at com.paritytrading.nassau.soupbintcp.SoupBinTCPServer.packet(SoupBinTCPServer.java:148)
        at com.paritytrading.nassau.soupbintcp.SoupBinTCPSession.parse(SoupBinTCPSession.java:125)
        at com.paritytrading.nassau.soupbintcp.SoupBinTCPSession.receive(SoupBinTCPSession.java:93)
        at com.paritytrading.parity.system.Events.receive(Events.java:95)
        at com.paritytrading.parity.system.Events.run(Events.java:68)
        at com.paritytrading.parity.system.TradingSystem.main(TradingSystem.java:47)
        at com.paritytrading.parity.system.TradingSystem.main(TradingSystem.java:27)

    This Exception occurs when I start placing BUY/SELL orders via JMeter and increase the number of Threads to place orders.
    This Threads Threshold to cause Exception is different and it seems depends on the CPU of the machine(3 Threads on Cloud vs 5 Threads on my local laptop).
    I use the latest version of POE protocol, and read this:
    https://gitter.im/paritytrading/chat/archives/2019/05/30
    paritytrading/parity@e432eb3

    Any idea how I can fix this issue?

    Jussi Virtanen
    @jvirtanen
    How do you place orders from JMeter? Have you implemented a custom client that speaks the POE protocol? If you use Nassau for SoupBinTCP support, note that a single Nassau SoupBinTCP connection is generally not safe for accessing from multiple threads.
    Vladyslav Ilchenko
    @Zenceras
    Thank you for your answer. My Parity Clients work on top of standard Parity Client and use the original mechanism for order placing. I added REST endpoint on top of Parity Client for external order placing but after your answer, I think the first problem was in concurrency when multiple REST requests came in Parity Client, now I changed Parity Client design and grab orders from the Queue and increase the number of Parity Clients(for different Users) - 6 100% loaded Parity Clients works very good with one Parity System, Reporter, and Ticker and I increasing number of this Parity Clients, simultaneously fixing hi-load issues in the other part of my system. Thank you again for your answer and you super system, which allowed even me build working prototype of the exchange.