kazdragon / telnetpp Goto Github PK
View Code? Open in Web Editor NEWA C++ library for interacting with Telnet streams
License: MIT License
A C++ library for interacting with Telnet streams
License: MIT License
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.
Want to be able to call generate on collections, not just iterator pairs.
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:
This should be a simple subnegotiationless client.
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.
E.g. by integrating MCCP with Paradice and using TinTin++ with the option enabled.
Should contain cmake scripts, Travis scripts, and basic testing environment.
The NAWS Server is responsible for maintaining a screen size, sending it upon activation and thence whenever it is set.
If configured, for example, with -DBUILD_SHARED_LIBS=1, then it may be acceptable to install as a versioned (see SOVERSION property) .so file.
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.
These can be gleaned from various RFCs, or just picked from Paradice9.
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.
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.
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.)
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.
MCCP can be internally validated by streaming data to and from MCCP server and clients.
Must be capable of transforming a stream of bytes into a stream of commands, negotiations, and subnegotiations.
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.
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.
Add something like telnetpp/telnetpp.hpp which includes all the main headers (e.g. routers, parser, generator, etc.)
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.
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.
A Session object should be able to handle all unrouted negotiations with default negative responses.
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).
There's really no Telnet going on without those things in element.hpp, so it should go into core.
Must be capable of transforming a stream of TELNET commands, negotiations, subnegotiations and ordinary text into a stream of bytes.
A NAWS Client is responsible for interpreting subnegotiations from a server and reporting any changes in screen size that it sends.
An option should be able to:
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.
Acceptance test for MSDP - actually have it working with a real-life MSDP client.
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.
Not a specific task of the library itself, but it's really necessary to have this working in a product before release.
Activatable options will be dormant by default, but will respond positively to requests to active that originate from the remote end.
In particular:
It is currently set to 0; it should be 1.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.