|
Class SlipFramingElement
|
The SLIP framing element leverages the scattering/gathering optimation of the
transport com.newstep.solid.netio.StreamChannel implementation
in order to read as much data on each
read as possible. Since the payload size is unknown prior to reading the
header, the most efficient scheme involves priming the read by reading a
header and then attempting to read both the payload and the header of the
next message. As such the Slip framing element leverages a java.nio.ByteBuffer array
structures as the payload ByteBuffer first followed by the fixed
(preallocated) header ByteBuffer.
In addition, the SlipFramingElement must empty the buffer on each read
notification. As such, the framing element continues to read until it is
unable to completely read either a full header or a full payload.
In processing the header, the framing element allocates the prescribed
payload buffer and proceeds to read the payload (and next header). In
processing the payload the framing element constructs a SlipMessage and
pushes it to the its associated com.newstep.solid.netio.ProtocolListener
(SlipChannel).
The header may be encoded as BYTE, UNSIGNED_BYTE, SHORT, UNSIGNED_SHORT,
or INT. In addition the header may be padded with empty bytes based on the
access point configuration. The framing element uses an associated
com.newstep.solid.netio.slip.codec.SlipMessageHeaderCodec
to provide the length encode/decode to and from the
scatter/gather ByteBuffers.
The SLIP framing element leverages the scattering/gathering optimation of the
transport com.newstep.solid.netio.StreamChannel implementation
in order to read as much data on each
read as possible. Since the payload size is unknown prior to reading the
header, the most efficient scheme involves priming the read by reading a
header and then attempting to read both the payload and the header of the
next message. As such the Slip framing element leverages a java.nio.ByteBuffer array
structures as the payload ByteBuffer first followed by the fixed
(preallocated) header ByteBuffer.
In addition, the SlipFramingElement must empty the buffer on each read
notification. As such, the framing element continues to read until it is
unable to completely read either a full header or a full payload.
In processing the header, the framing element allocates the prescribed
payload buffer and proceeds to read the payload (and next header). In
processing the payload the framing element constructs a SlipMessage and
pushes it to the its associated com.newstep.solid.netio.ProtocolListener
(SlipChannel).
The header may be encoded as BYTE, UNSIGNED_BYTE, SHORT, UNSIGNED_SHORT,
or INT. In addition the header may be padded with empty bytes based on the
access point configuration. The framing element uses an associated
com.newstep.solid.netio.slip.codec.SlipMessageHeaderCodec
to provide the length encode/decode to and from the
scatter/gather ByteBuffers.
The SLIP framing element leverages the scattering/gathering optimation of the
transport com.newstep.solid.netio.StreamChannel implementation
in order to read as much data on each
read as possible. Since the payload size is unknown prior to reading the
header, the most efficient scheme involves priming the read by reading a
header and then attempting to read both the payload and the header of the
next message. As such the Slip framing element leverages a java.nio.ByteBuffer array
structures as the payload ByteBuffer first followed by the fixed
(preallocated) header ByteBuffer.
In addition, the SlipFramingElement must empty the buffer on each read
notification. As such, the framing element continues to read until it is
unable to completely read either a full header or a full payload.
In processing the header, the framing element allocates the prescribed
payload buffer and proceeds to read the payload (and next header). In
processing the payload the framing element constructs a SlipMessage and
pushes it to the its associated com.newstep.solid.netio.ProtocolListener
(SlipChannel).
The header may be encoded as BYTE, UNSIGNED_BYTE, SHORT, UNSIGNED_SHORT,
or INT. In addition the header may be padded with empty bytes based on the
access point configuration. The framing element uses an associated
com.newstep.solid.netio.slip.codec.SlipMessageHeaderCodec
to provide the length encode/decode to and from the
scatter/gather ByteBuffers.
| Field Summary | |
|---|---|
private ByteBuffer |
|
private final static String |
|
private final static int |
|
private ByteBuffer |
|
private SlipMessageHeaderCodec |
|
private int |
|
private int |
|
private LengthEncoding |
|
protected static Logger |
|
private int |
|
private ReadType |
|
ReadType |
HEADER |
ReadType |
PAYLOAD |
private final static int |
|
private final static int |
|
private StreamChannel |
|
private final static int |
|
private final static int |
|
| Constructor Summary | |
|---|---|
void |
SlipFramingElement(LengthEncoding lengthEncoding, Integer maxPayload, Integer headerPadding) |
| Method Summary | |
|---|---|
void |
|
void |
|
boolean |
|
public void |
|
boolean |
|
void |
setTransportChannel(StreamChannel transportChannel) |
public void |
write(ProtocolMessage message) |
Valid encodings are:
NOTE: values greater than those represented by signed integer are
not supported by the buffer allocation system and therefor not by the
SLIP protocol.
NOTE: this does not set the framing element as a listener because this is
done by the SlipAccessPoint on openChannel