Stream Flush

Flushes data from the stream buffer to the underlying communication channel.

Library

Description

The Stream Flush block writes the data in the stream buffer to the underlying communication channel. The operation of this block is affected by the blocking mode of the stream connected to its input. Streams have two modes: blocking (the default) and non-blocking. The blocking mode of the stream is determined by the Stream Connect or Stream Accept block which created the stream. The Stream Flush block cannot be used with streams created using the Stream Listen block.

This block attempts to send the contents of the stream buffer over the communication channel. If an error occurs, then it returns a negative error code at its err output. If the connection is closed it is considered an error condition.

If the stream is blocking, then this block waits until all the data in the buffer is sent before returning.

If the stream is non-blocking, then this block does not wait. It attempts to send all the data remaining in the stream buffer. However, if this operation would block then it returns -QERR_WOULD_BLOCK at its err output, even if it has already sent some of the data. In this case, the Stream Poll block may be used to determine when at least one more byte may be flushed.

This block does not support two threads calling Stream Flush or Stream Send at the same time. However, Stream Flush or Stream Send may be called by another thread at the same time as Stream Receive.

Helpful Hints

Datagram size and UDP

For packet or message-based protocols in non-blocking mode, the number of bytes sent over the communication channel in each packet may be larger than the number of bytes in the input signal. If the data cannot be flushed to the underlying communication channel without blocking then it remains in the stream buffer and will be written to the underlying communication channel along with the new data the next time the Stream Flush block is invoked. This situation is typically recognized when a QERR_DATAGRAM_TOO_LARGE error is returned at the peer when trying to receive the data.

The number of bytes in each packet may be as large as the stream buffer size unless the underlying protocol restricts the maximum packet size. For example, the bufsize option of the UDP protocol has a default value of 1492 bytes. Hence, up to 1492/8 = 186 doubles may appear in a single datagram at the peer if the stream buffer is more than 1492 bytes in size. To restrict the size of the datagrams sent, either reduce the stream buffer size or set the bufsize option of the UDP URI. Reducing the stream buffer size may cause new data to be discarded if there is not enough room in the stream buffer, but it limits the number of datagrams sent. Setting the bufsize option of the UDP URI causes the stream API to send multiple datagrams, if necessary, to flush the stream buffer. A typical URI would be "udp://localhost:18000?bufsize=512", which sets the maximum datagram size to 512 bytes (64 doubles).

An even better solution is to allow the datagrams to be large and instead receive the full datagram at the peer. For example, if the stream buffer size and maximum datagram size are both 1492 bytes, then attempt to receive 1492 bytes at the peer (or 187 doubles). For the Simulink blocks or stream API functions, that means using a stream buffer that is at least 1492 bytes in length at the peer. For the lower-level communications API, specify a buffer of at least 1492 bytes in the call to qcomm_receive.

Input Ports

stm

A reference to the stream created by the Stream Connect or Stream Accept block. If the stream is closed or is otherwise invalid then the negative error code -QERR_INVALID_STREAM is returned by the err output.

Output Ports

stm

A reference to the stream. This output is merely a copy of the stm input. Providing this output makes it much easier to establish the execution order of Stream blocks in the diagram because Simulink generally executes daisy-chained blocks in sequence.

err

An int32 value indicating the results of the operation. If all the data is flushed to the underlying communication channel then a value of zero is output. If an error occurs then this value is a negative error code. If the stream is non-blocking and some of the data in the stream buffer could not be flushed to the underlying communication channel without blocking then -QERR_WOULD_BLOCK is output and the block returns immediately. See Error Codes for the different error codes and their values. Use the Compare to Error block rather than the error code itself to check for specific error codes. To check for errors in general use the Compare to Zero block to check whether len is less than zero.

Parameters and Dialog Box

The Stream Flush block has no parameters.

Targets

See Also

• Stream Listen block
• Stream Connect block
• Stream Send block
• Stream Receive block
• Advanced Communications
• MATLAB Stream Functions
• Communications Using the C Language

Copyright ©2024 Quanser Inc. This page was generated 2024-10-17. Submit feedback to Quanser about this page.

Link to this page.