paritytrading / nassau Goto Github PK

Currently, Nassau's only dependency is Foundation. It would be nice if Nassau didn't have this dependency.

The BinaryFILE reader should expose the end-of-stream. This could be achieved by changing the read method to return the number of bytes read, possibly zero, or -1 if the it has reached the end-of-stream.

Add a client parameter to MoldUDP64ClientStatusListener and SoupBinTCPClientStatusListener and a server parameter to SoupBinTCPServerStatusListener. An example:

void state(MoldUDP64Client client, MoldUDP64ClientState next);

The MoldUDP64 client uses the same channel for receiving downstream packets and sending request packets. While this works fine, it means that no more than one client instance listening to a particular session can be running on a host at a time. (This is because the source UDP port in request packets from all client instances equals the multicast UDP port. All downstream packets sent as unicast datagrams in response to request packets are always forwarded by the operating system to one of the many sockets bound to the multicast UDP port.)

The MoldUDP64 client should use a separate channel for sending request packets.

Hi,
I came across this repo which searching for pcap files for different exchange protocols (MoldUDP64, SoupBINTCP, ITCH, OUCH etc)
In case you have tcpdump's for these protocols can you please share them.
Regards
Vijay

Nassau SoupBinTCP Performance Test is currently implemented in such a a way that the next packet is sent out right after receiving the previous packet. This is wrong and known as coordinated omission, because it does not take into account the adverse effect long processing time of one packet would have on subsequent packets in the real world.

Eliminate coordinated omission by sending packets at regular intervals.

The MoldUDP64 client goes to the SYNCHRONIZED state as soon as it receives a downstream packet with a sequence number no greater than expected. It should actually track the highest received sequence number and stay in the BACKFILL or GAP_FILL state until the expected sequence number is greater than the highest received sequence number.

Nassau does not currently compile on JDK 11, most likely due to the Error Prone usage.

A MoldUDP64 performance test would be interesting. Might implement this.

Nassau SoupBinTCP Performance Test is a multithreaded application that runs a SoupBinTCP client on one thread and a SoupBinTCP server on another. While it can be used to measure the round-trip time (RTT) over the loopback interface, it would be beneficial to be able to run the endpoints on different hosts.

In the spirit of Philadelphia's Philadelphia Test Acceptor and Philadelphia Test Initiator the application could be split into Nassau SoupBinTCP Test Client and Nassau SoupBinTCP Test Server and placed in an examples directory:

examples/soupbintcp-client
examples/soupbintcp-server

Hi,

Do you have an estimate on when a new version will be released to Maven Central?

Thanks
Ed

The MoldUDP64 client should keep track of the highest sequence number received and, as soon as it receives a downstream packet, send a request packet if the highest sequence number has not yet been reached sequentially.

Currently the MoldUDP64 client sends a request packet if it receives a downstream packet with higher than expected initial sequence number.

The MoldUDP64 client should expose its state to the application. The state could be represented by the following enumeration:

• BACKFILL
• SYNCHRONIZED
• GAP_FILL

The client would be initially in the BACKFILL state. As soon as it reaches synchronization with the MoldUDP64 server, it goes to the SYNCHRONIZED state. Should it fall out of synchronization with the server while in the SYNCHRONIZED state, it goes to the GAP_FILL state until it regains synchronization.

The BinaryFILE recorder should support NASDAQ SoupBinTCP 3.00 as a transport protocol in addition to NASDAQ MoldUDP64 1.00.

The default MoldUDP64 message store uses blocks comprising of byte arrays for message storage. The default block size is 64 MB.

Allocating a byte array of 64 MB is slow. Much smaller byte arrays or alternative techniques, such as off-heap memory, should be investigated.

At the moment it is possible to set the SoupBinTCP receive buffer size to a value lower than the length of, for example, the Login Request packet. Fix this by setting a lower bound for the parameter.

Leveraging from some of the other projects you have been involved in is it possible to add more native protocols.

How can i use this to talk to an SSL SoupBinTCP Server ? tried and i'm getting a connection refused/reset error

It looks like there is a way to configure JDK 10 or later for Travis using a tool called install-jdk.sh. It would be good to amend the Travis configuration to contain the following JDKs:

• Oracle JDK 8
• OpenJDK 11

Note. Oracle JDK 9 and Oracle JDK 10 have reached end-of-life earlier this year. At the moment OpenJDK 11 does not work due to #52.