kazdragon / telnetpp Goto Github PK

At the bottom of the protocol stack, it is necessary to output just a straightforward stream of bytes. But, before that takes place, it is necessary to filter out the boost::any tags/objects that may be in the vector of tokens.

This filter should be supplied by the library, rather than having every user of the library re-implement it.

Note: all boost::any objects should have been consumed by this point in time, so these can be treated as errors if they remain present.

Documentation (especially the readme, which states to do this manually) should be updated to reflect this feature.

An option should be able to:

• register with routers to receive negotiations and subnegotiations that target the option
• know and pro-actively report on the state of the option.

A subnegotiationless option implements only basic functionality. In general, this is used to enable or disable a feature in another layer of the application (e.g. echo, suppress go-ahead, etc.)

There's really no Telnet going on without those things in element.hpp, so it should go into core.

A Session object should be able to handle all unrouted negotiations with default negative responses.

The vector<token, any> interface is still somewhat clunky, and could do with investigating to see if it can be made cleaner.

Ideally, this would occur after the implementation of the MCCP option, since the clunkiness exists to serve that particular option in the first place.

In particular:

• Overall intent of library
• Datastream-agnosticism
• How to use the library in other code

http://tools.ietf.org/html/rfc1572

Want to be able to call generate on collections, not just iterator pairs.

At the moment, it is assumed that everything that is transmitted to and from the layer below is a stream of bytes.

Although it must be that a stream of bytes is indeed received and transmitted, other types should be passed through.

http://tintin.sourceforge.net/mccp/

At the moment, parser only knows about vectors. And it should stay that way.

It needs a helper, though, since telnetpp will require a stream of (vector | any), and those anys must be passed through.

Therefore, we need a parser helper that accepts the compound type and returns a vector, where all the vectors have been buffered up and parsed into elements, and all the anys have been passed through.

Note: the anys must be passed through as close to their reception point as necessary. It's expected that these will always occur on element boundaries within the streams, but it's not necessarily true.

All options with no subnegotiations can be generalised as options that are templated upon the option number, rather than having a separate source for each.

http://tintin.sourceforge.net/msdp/

A NAWS Client is responsible for interpreting subnegotiations from a server and reporting any changes in screen size that it sends.

MCCP can be internally validated by streaming data to and from MCCP server and clients.

std::vector cannot implement any kind of small buffer optimization. This means that every non-0-length vector requires a memory allocation.

Consider replacing usages std::vector with an alternative type that uses SBO. For example:

• boost::containers::small_buffer<T, S>
• std::basic_string

On GCC, building a static library with hidden symbols and linking it into a share library causes link time errors.

The CMake setting for this should therefore be reviewed.

Now that #95 is complete, it should be possible to cache the GTest build so that it doesn't need to be done every time.

See http://tintin.sourceforge.net/mccp/

See: http://www.stack.nl/~dimitri/doxygen/manual/commands.html#cmdmainpage

This should contain enough information for a new user to be able to use the library's basic functions. See README.md for inspiration.

http://tools.ietf.org/html/rfc1572

Activatable options will be dormant by default, but will respond positively to requests to active that originate from the remote end.

Acceptance test for MSDP - actually have it working with a real-life MSDP client.

These can be gleaned from various RFCs, or just picked from Paradice9.

Not a specific task of the library itself, but it's really necessary to have this working in a product before release.

http://tintin.sourceforge.net/msdp/

Add something like telnetpp/telnetpp.hpp which includes all the main headers (e.g. routers, parser, generator, etc.)

Some good usage for target_link_libraries can be found here: http://stackoverflow.com/a/26038443/24913

In particular, ZLib should be part of the private link declarations of the telnetpp library.

If configured, for example, with -DBUILD_SHARED_LIBS=1, then it may be acceptable to install as a versioned (see SOVERSION property) .so file.

Must be capable of transforming a stream of bytes into a stream of commands, negotiations, and subnegotiations.

E.g. by integrating MCCP with Paradice and using TinTin++ with the option enabled.

It is currently set to 0; it should be 1.

It's difficult to use CppUnit with Clang's memory sanitizer. Therefore, it may be of more use to move to a different testing infrastructure.

According to the TELNET Standard, Commands are initiated by bytes from 0xEF (239) to 0xFF (255). For the purposes of this issue, this will exclude the bytes between 0xFA (250) and 0xFE (254), since these represent SB, WILL, WONT, DO and DONT, which are for Subnegotiations and Negotiations.

This should be a simple subnegotiationless client.

The Router Framework would allow a user to set handlers for the different Telnet token types, and for default handling of unregistered options. This would also include a method for passing a token from a stream of tokens to an appropriate router (e.g. command router, negotiation router).

Most protocol headers expose constants to do with the protocol: option numbers, constants, etc. However, users never have to deal with these, so they should be private to the library.

The NAWS Server is responsible for maintaining a screen size, sending it upon activation and thence whenever it is set.

Should contain cmake scripts, Travis scripts, and basic testing environment.

Must be capable of transforming a stream of TELNET commands, negotiations, subnegotiations and ordinary text into a stream of bytes.

A TT Client is responsible for querying a server's terminal types. Upon receipt of these types, they should be reported to an upper layer. There should be no more logic than this, since the way in which this data is received may differ from application to application - some may wish to cycle through all types, some may be satisfied with only one type.