Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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.
    crowlogic
    @crowlogic
    REST sucks
    anyone using it is smoking crack
    Toby Considine
    @TobyConsidine
    Do you have any advice for implementing package deals with Parity?
    By Package Deal, I mean bundling an order for more than one instrument, and either trading all of them, or none of them.
    I am using Parity to Transactive Energy Markets to operate Microgrids. Consider for this question that a Microgrid spans a neighborhood or an Industrial park. The microgrid balances electrical power supply and use over time by means of a local (within the microgrid) market. The model is recursive, as any node in a microgrid may itself be a microgrid operated by its own micromarket; any microgrid may be a participant in a larger microgrid/market. Each fractal microgrid can be operated by a micromarket.
    We are treating each time at each granularity as an instrument. For each day, we spin up 24 parity markets as the first wholesale tenders arrive. We destroy the markets with outdated instruments, and so on. If a microgrid also supports a different granularity, say a 5 minute market, we spin up Parity engines for those as well.
    All purchases are committed (of course) so participants can sell back into the market, converting the market from a single-price giver to multiple participants. Distributed energy sources can sell into the local markets. Batteries become essentially day traders on their own accounts. Some markets may permit purely financial participants.
    Let’s stick with a one hour granularity. An industrial process may need to buy three consecutive hours of power to operate. Our agents should tender three instruments as a Package, able to acquire all three or none.
    I don’t see any obvious way to do this, but I have likely missed something. Any advice?
    Susith Hemathilaka
    @Susith1995
    As a beginner have Any guide or reference please?
    Susith Hemathilaka
    @Susith1995
    any ideas about handling heartbeat?
    Jan Nielsen
    @JanStureNielsen
    @TobyConsidine -- if I understand your "package deal" idea correctly, these types of orders are called "combination orders": https://www.investopedia.com/terms/c/combination.asp
    Jan Nielsen
    @JanStureNielsen
    Jan Nielsen
    @JanStureNielsen
    From your description, it sounds like you'd like "guaranteed combination orders" so you will need to build a "guaranteed combination order matching engine". To do this with performance, will hinge on how narrowly you can constrain the guarantees. If you live with non-guaranteed combination orders, you might be able to use the existing matching engine and orders and deal with the "combination" notion at the application layer. This is will much easier to do but without guarantees.
    Toby Considine
    @TobyConsidine
    Thanks, Jan. Those clues should keep me busy for a while.
    Jussi Virtanen
    @jvirtanen
    Hi @TobyConsidine, @JanStureNielsen gave good pointers. I'm also not very familiar with multi-leg or combination orders, but I have a feeling that they are usually implemented on a higher level than the matching engine. In principle, if you have one gateway through which orders onto individual order books are placed, then that gateway can also decide based on the current state of the associated order books (received via the market data protocol) whether to accept or reject the combination order by inspecting the available liquidity on each associated order book.
    Hi @Susith1995! Re: heartbeat, which project are you talking about?
    Jaffer Wilson
    @JafferWilson
    Hi @jvirtanen Let meknow if there is backtest facility in Parity?
    Is it similar or better than MT 4/5?
    Jussi Virtanen
    @jvirtanen
    Hi @JafferWilson! No, there is no backtest facilities.
    Zeeshan M
    @negati-ve

    Is parity project still maintained?

    last release was in 2017

    Jussi Virtanen
    @jvirtanen
    Hi @negati-ve! Most development these days takes place in Philadelphia.
    beratkirik
    @beratkirik

    java -jar parity-sim.jar etc/devel.conf
    fatal: Connection reset by peer

    java.io.IOException: Connection reset by peer
    at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
    at sun.nio.ch.IOUtil.read(IOUtil.java:197)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:377)
    at com.paritytrading.nassau.soupbintcp.SoupBinTCPSession.receive(SoupBinTCPSession.java:86)
    at com.paritytrading.parity.sim.Events.run(Events.java:66)
    at com.paritytrading.parity.sim.Simulator.main(Simulator.java:55)
    at com.paritytrading.parity.sim.Simulator.main(Simulator.java:26)

    when i try to connect parity system via tcp i have this messages from simulator , ticker and reporter

    Juan Cruz Borba
    @juanceborba_gitlab
    @jvirtanen Hi Jussi, I´m trying to use your platform to build an exchange. I´m trying to understand why the multicast (nassau) does not work. I´m using your parity docker implementation. I can use the parity system to add orders and I can read the orders added using my own service. But I can´t to read it from your another applications. So, my question is: Does your docker project works for multicast or should try with yur Genesis implementation?
    Dimitar Dimitrov
    @ddimtirov
    @juanceborba_gitlab IGMP is not routed over Docker overlay networks, so if you use multicast make sure you are using the "host" networking. If you do need overlays, you'd need to configure the Weave network driver. IPVLan may also work, though I haven't tried it.
    Ian McKane
    @iammckane
    Hi @jvirtanen - I'm using parity-docker. Connecting via FIX as an initiator is ok. But I have noticed that when there is a sequence number mismatch on logon, the parity FIX server sends a resendrequest (2) in reply to the client login that is missing the targetcompid(56). That makes it an invalid message that and can cause a session level reject in reply.
    Jussi Virtanen
    @jvirtanen
    Hi @beratkirik! Please note that the simulator is only compatible with Parity 0.6.0, not Parity 0.7.0.
    Hi @iammckane! That sounds like a Philadelphia issue. Thank you for reporting, I will take a look. :mag:
    Jussi Virtanen
    @jvirtanen
    Hi @juanceborba_gitlab! As @ddimtirov mentioned, there are additional requirements regarding Docker and multicast. You can either configure our Docker environment or e.g. use a SoupBinTCP gateway to provide the feeds over TCP rather than multicast UDP. The latter is actually done in the Docker example as well.
    Marquis Wang
    @marquiswang
    hello. I'm interested in using parity to build an exchange. I'm curious whether already exists any persistence/database support to keep data across restarts, or I would need to build that myself. thanks!
    Marquis Wang
    @marquiswang
    also, does TCP reporting/data still work?
    Dimitar Dimitrov
    @ddimtirov
    Hi @jvirtanen, I am using Philadelphia FIX to build a diagnostic/test client for our needs, and I love the level of control it gives us (i.e. I can stop sending heartbeats, scan fuzz messages, etc.) One thing I find missing is being able to peek at raw messages before they are handled by the FIX session logic.
    Example scenario: when we logon with seq ID too low, the remote side of a FIX application would reply with a logout. The problem is that my application cannot see the logout because it has a sequence ID higher than rcvId, so Philadelphia automatically requests resent.
    Dimitar Dimitrov
    @ddimtirov
    It would be nice to have a hook where we can intercept buffers, and inspect the incoming and outgoing "raw" messages with option to swallow. This should also allow us to fudge things, such as simulate bad checksums, or update fields. The goal is to extend the testing scenarios we can handle.
    Dimitar Dimitrov
    @ddimtirov
    Actually I was able to handle my particular use-case by extending FIXConnectionand overriding message(m) - still having interception points for the buffer and message immediately after parsing would be a welcome addition.
    Dimitar Dimitrov
    @ddimtirov
    Spoke too soon... What ended up working is:
    private static void interceptRaw(FIXConnection connection, Function<FIXMessage, FIXMessage> interceptor) {
        try {
            Field parserField = connection.getClass().getDeclaredField("parser");
            parserField.setAccessible(true);
            FIXMessageParser parser = (FIXMessageParser) parserField.get(connection);
            Field listenerField = parser.getClass().getDeclaredField("listener");
            listenerField.setAccessible(true);
            FIXMessageListener sink = (FIXMessageListener) listenerField.get(parser);
    
            listenerField.set(parser, (FIXMessageListener) (FIXMessage m) -> {
                FIXMessage intercepted = interceptor.apply(m);
                if (intercepted!=null) sink.message(intercepted);
            });
        } catch (NoSuchFieldException | IllegalAccessException e) {
            e.printStackTrace();
        }
    }
    it is rather ugly, but does the job
    Nitesh Agarwal
    @nagarwa2
    Hi @jvirtanen , sometimes we don't receive Parity Accepted event for an order ? Can we do something to avoid this ?
    Jussi Virtanen
    @jvirtanen
    Hi @nagarwa2! I assume you don't get Order Rejected messages either. Do you keep your TCP connections up after sending in an order?
    Hi @ddimtirov! Yes, I've also thought about making it possible to define your own handling for all messages, including all administrative messages, in Philadelphia. Now that you, too, have raised this up, I'll take another look on how that could look like. :thumbsup:
    Jussi Virtanen
    @jvirtanen
    Hi @marquiswang! No, there's no persistence support built-in. If you are thinking of building anything on top of Parity, do note the limitations the NASDAQ MoldUDP64 transport protocol sets for market hours.
    Nitesh Agarwal
    @nagarwa2
    @jvirtanen We are keeping the TCP connection alive. Strange thing is when we resend that order we do get the accepted command. This is not happening that frequently.
    Jussi Virtanen
    @jvirtanen
    @nagarwa2 Have you managed to capture a tcpdump of such a situation?
    Nitesh Agarwal
    @nagarwa2
    Hi @jvirtanen I was not able to get the TCP dump, but noticed a strange thing. I received a order rejected event with reason 73 and just microsecond after that received order accepted event for same order but detail such as (price, quantity) do not match of that order. Is this possible ?
    Toby Considine
    @TobyConsidine
    I have been asked about using the Parity engine with the FIX network reliability protocols (SBE and FIXP) rather than with the NASDAQ / Nausau protocols (MOLDUDP). Has anyone doe this already? Does anyone have and advice? Should I be switching to the Philadelphia codeset instead?
    Jussi Virtanen
    @jvirtanen
    @nagarwa2 Anything is possible. :wink: What do you use for interacting with Parity (the POE/SoupBinTCP implementation)?
    Hi @TobyConsidine! Philadelphia does not implement SBE and FIXP, only the "classic" FIX tag-value format; I suggest looking at Simple Binary Encoding instead.