FAST Message length in TCP

, ,
1

Imported from previous forum

2

In FAST 1.0 mention that length of FAST message is send as the initial part of the FAST Stream. but that is not mention in FAST 1x1. Then how receiver identifies the length of FAST buffer? Specially in TCP (NOT in UDP) Single message can receive as two or more packets. Pls help me.

3

Janaka,

In FAST 1.0 mention that length of FAST message is send as the initial
part of the FAST Stream. but that is not mention in FAST 1x1.

Please refer to the FAST 1x1 spec, section 10 Transfer Encoding
I believe you are referring to a stream of blocks
(blocks aren’t used in any of the current live feeds)

Then how receiver identifies the length of FAST buffer?

Short answer: It cannot beforehand.

The decoder must read the message incrementally and do any additional read operations from the network (normally via a socket read/recv/…) as needed.

This is an implementation issue.

Specially in TCP (NOT in UDP) Single message can receive as two or
more packets.

Pls help me.

Hope this helps,
Rolf

4

Clarification:

The decoder must read the message incrementally and do any additional
read operations from the network (normally via a socket read/recv/…)
as needed.

unless a blocked stream is used. With a blocked stream you can read a full block by reading the block size and the number of bytes indicated by the block size.

/Rolf

Janaka,

In FAST 1.0 mention that length of FAST message is send as the initial
part of the FAST Stream. but that is not mention in FAST 1x1.

Please refer to the FAST 1x1 spec, section 10 Transfer Encoding I
believe you are referring to a stream of blocks (blocks aren’t used in
any of the current live feeds)

Then how receiver identifies the length of FAST buffer?

Short answer: It cannot beforehand.

The decoder must read the message incrementally and do any additional
read operations from the network (normally via a socket read/recv/…)
as needed.

This is an implementation issue.

Specially in TCP (NOT in UDP) Single message can receive as two or
more packets.

Pls help me.

Hope this helps, Rolf

5

So, a block stream can be used with TCP and may contain one message per block with no implicit dictionary reset.

-Nav

Clarification:

The decoder must read the message incrementally and do any additional
read operations from the network (normally via a socket read/recv/…)
as needed.

unless a blocked stream is used. With a blocked stream you can read a
full block by reading the block size and the number of bytes indicated
by the block size.

/Rolf

Janaka,

In FAST 1.0 mention that length of FAST message is send as the
initial part of the FAST Stream. but that is not mention in
FAST 1x1.

Please refer to the FAST 1x1 spec, section 10 Transfer Encoding I
believe you are referring to a stream of blocks (blocks aren’t used in
any of the current live feeds)

Then how receiver identifies the length of FAST buffer?

Short answer: It cannot beforehand.

The decoder must read the message incrementally and do any additional
read operations from the network (normally via a socket read/recv/…)
as needed.

This is an implementation issue.

Specially in TCP (NOT in UDP) Single message can receive as two or
more packets.

Pls help me.

Hope this helps, Rolf

6

yes, that’s correct.
A block may contain one or more messages and it doesn’t imply a reset.
/Rolf

So, a block stream can be used with TCP and may contain one message
per block with no implicit dictionary reset.

-Nav

7

yes, that’s correct. A block may contain one or more messages and it
doesn’t imply a reset. /Rolf

So, a block stream can be used with TCP and may contain one message
per block with no implicit dictionary reset.

-Nav

Thanks,
Nav