QuickFAST As a Server

[Jared White]

My apologies for posting this as a reply in another thread, and as its
own proper thread here. I have a question about how I might use
QuickFAST to implement both a client and server protocol.

Does anyone know if we can use QuickFast as both a client and a
server? For example, I want to use QuickFast to send application-
specified data (not financial / exchange typed data) from one system
to another. I want to run a server that provides data to its
clients. I'm intending for all clients to use QuickFast, but can the
server use QuickFast in server mode?

Does anyone know how else one might create a server based FAST
protocol implementation quickly?

Regards,
-Jared

[Malcolm Spence]

Hi Jared, have you read this article?

http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201001.html

It explains how you can take decoded data from QuickFAST and place its data
into a real time data distribution service framework.

regards Malcolm
Malcolm D. Spence
Director of Business Development
OCI St. Louis MO USA
www.ociweb.com

"Use our reach to help exceed your grasp."
TEL: 1-314-590-0206
FAX: 1-314-579-0065

--------------------------------------------------
From: "Jared White" <jaredke...@gmail.com>
Sent: Thursday, August 19, 2010 7:40 PM
To: "quickfast_users" <quickfa...@googlegroups.com>
Subject: [quickfast_users] QuickFAST As a Server

> --
> You received this message because you are subscribed to the Google Groups
> "quickfast_users" group.
> To post to this group, send email to quickfa...@googlegroups.com.
> To unsubscribe from this group, send email to
> quickfast_use...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/quickfast_users?hl=en.
>
>

[Jared White]

Malcolm,

Thanks for this link. I had not read that article, but it gives me
quite a few good ideas for how I might use OpenDDS rather than a
traditional Client/Server approach.

I am thinking that I could have my transport path look like this:

Server Application => QuickFAST encode => OpenDDS => QuickFAST decode
=> Client Application

Of course, the reverse direction could also apply.

Is that what you were thinking?

Regards

On Aug 19, 8:51 pm, "Malcolm Spence" <spenc...@ociweb.com> wrote:
> Hi Jared, have you read this article?
>
> http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201001.html
>
> It explains how you can take decoded data from QuickFAST and place its data
> into a real time data distribution service framework.
>
> regards Malcolm
> Malcolm D. Spence
> Director of Business Development
> OCI St. Louis MO USAwww.ociweb.com
>
> "Use our reach to help exceed your grasp."
> TEL: 1-314-590-0206
> FAX: 1-314-579-0065
>
> --------------------------------------------------

> From: "Jared White" <jaredkeithwh...@gmail.com>

[Malcolm Spence]

yes that was what the article was intended to show. We take about a
microsecond to decode. Then we can filter the data, according to your needs,
drop it in a topic publisher and send it out directly to subscribers to that
topic..

The DDS spec uses strongly typed data which actually reduces the data
marshalling at the receiver end. The overall result is quite deterministic
delivery, and is highly scalable.

A few weeks later we did more analysis comparing Boost ASIO, ZeroMQ and
OpenDDS. as you might expect the lightweight messaging put more load on the
apps for subsequent processing so overall there was not much difference in
performance. A sort of pay me now or pay later model.

When we run OpenDDS in a rack the box to box communication latency (TCP/IP)
is about 28 microseconds. Using native Infiniband we expect that to drop to
around 3 microseconds.

So there are plenty of opportunities left to improve overall latency.

regards Malcolm
Malcolm D. Spence
Director of Business Development
OCI St. Louis MO USA
www.ociweb.com

"Use our reach to help exceed your grasp."
TEL: 1-314-590-0206
FAX: 1-314-579-0065

--------------------------------------------------
From: "Jared White" <jaredke...@gmail.com>
Sent: Thursday, August 19, 2010 8:19 PM
To: "quickfast_users" <quickfa...@googlegroups.com>
Subject: [quickfast_users] Re: QuickFAST As a Server

[Jared White]

Malcolm,

Those are great numbers to know. Most of our communciation would be
from server rack (in the data center) to a local machine (client in an
office) over TCP/IP and would be monitoring traffic. The traffic
isn't nearly as intense as, say, an ARCA Tape A feed, but could reach
the 2MB/s range easily. We don't envision that it would scale much
higher than that for less than 50 clients.

Thanks again for the information.
-Jared

On Aug 19, 11:06 pm, "Malcolm Spence" <spenc...@ociweb.com> wrote:
> yes that was  what the article was intended to show. We take about a
> microsecond to decode. Then we can filter the data, according to your needs,
> drop it in a topic publisher and send it out directly to subscribers to that
> topic..
>
> The DDS spec uses strongly typed data which actually reduces the data
> marshalling at the receiver end. The overall result is quite deterministic
> delivery, and is highly scalable.
>
> A few weeks later we did more analysis comparing Boost ASIO, ZeroMQ and
> OpenDDS. as you might expect the lightweight messaging put more load on the
> apps for subsequent processing so overall there was not much difference in
> performance. A sort of pay me now or pay later model.
>
> When we run OpenDDS in a rack the box to box communication latency (TCP/IP)
> is about 28 microseconds. Using native Infiniband we expect that to drop to
> around 3 microseconds.
>
> So there are plenty of opportunities left to improve overall latency.
>
> regards Malcolm
> Malcolm D. Spence
> Director of Business Development