Introduction
The SLIP Protocol
The sliplib module implements the encoding and decoding
functionality for SLIP packets, as described in RFC 1055.
It defines encoding, decoding, and validation functions,
as well as various classes that can be used to wrap
the SLIP protocol over different kinds of byte streams.
The SLIP protocol uses four special byte values, defined in the config configuration object.:
Name |
Byte value |
Purpose |
|---|---|---|
|
To delimit messages. |
|
|
||
|
The escaped value of the |
|
|
The escaped value of the |
An END byte in the message is encoded as the sequence
ESC+ESC_END (b"\xdb\xdc")
in the slip packet,
and an ESC byte in the message is encoded
as the sequence ESC+ESC_ESC (b"\xdb\xdd").
Name |
Decoded |
Encoded |
|---|---|---|
|
|
|
|
|
As a consequence, an ESC byte in an encoded SLIP packet
must always be followed by an ESC_END or an ESC_ESC byte;
anything else is a protocol error.
Protocol variations
RFC 1055 specifies that the sender of a SLIP packet simply starts sending the encoded data,
followed by an END byte after the last byte of the packet.
The RFC also mentions an alternative approach,
where an END byte is sent both before the first byte
and after the last byte of the packet.
This is meant to minimize the possibility that line noise during the establishment of a connection
is interpreted as data in a SLIP packet.
This approach has the effect that the receiver will
see two back-to-back END bytes between subsequent packets.
Therefore, this works only when the receiver treats those subsequent END bytes
as a single END byte.
In the sliplib package, SLIP packets are constructed by instances of the Driver class.
Whether an END byte is included as the first byte of a SLIP packet is a setting
in those instances, determined by the config.USE_LEADING_END_BYTE
configuration value at the time the instances are created.
To accommodate receivers that do not work well with multiple END bytes between SLIP packets,
the default value of config.USE_LEADING_END_BYTE is False.
However, some receivers may require received SLIP packets
to have both a leading and trailing END byte.
For those cases the value of config.USE_LEADING_END_BYTE
can be set to True.
Note
The setting of config.USE_LEADING_END_BYTE does not affect
how sliplib handles received END bytes. Independent of the setting,
the sliplib code will always handle multiple subsequent END bytes
as a single END byte.
Important
The behavior of Driver instances is determined
by the value of config.USE_LEADING_END_BYTE
at the time the instance is created,
either directly or through the instantiation of a SlipWrapper subclass.
Any change to config.USE_LEADING_END_BYTE
after the instance is created does not affect the behavior of that instance.
The only exception to this rule is with the SlipSocket.accept() method.
When the accept() method is called
on a SlipSocket instance server,
it returns a new SlipSocket instance with the same behavior as server,
regardless of the current value of config.USE_LEADING_END_BYTE.
If an application needs to always use leading END bytes,
it is recommended to import slip.config
at the start of the application, and immediately set
config.USE_LEADING_END_BYTE
to True before creating any sliplib objects.
If the application needs multiple connections, some of which require a leading END byte
and others that require the absence of a leading END byte,
the use of the use_leading_end_byte() context manager is recommended.
Changed in version 0.7.0: Changed default behavior to not sending a leading END byte.