This project is read-only.

Examples | Troubleshooting / FAQs | References / Credits | Developers notes

Purpose of the application

TelnetC# is a telnet client written in C#. Its main purpose is to serve in a scenario where you have to talk to a telnet server, parse the output, process it, and afterwards respond in an appropriate way. The basic concept can be best understood by examples which you will find below in an own chapter.

The following features are supported:

  1. TelnetC# emulates a screen ("virtual screen").

  2. Search: Find expressions on this virtual screen either by string search, or regular expressions.

  3. Scrolling of the virtual screen.

  4. Cursor movements, erase commands.

  5. NAWS: Negotiation about window size.

Currently not supported:

  1. Setting of cursor positions.

  2. Text attributes as bold or colors. However, this does not make really sense considering the main goal: batch processing.

A little background

Once in a project my  task was to talk to a router via the Telnet protocol. My first idea: "Oh, this will be easy". I was thinking of telnet pretty much as of HTTP or FTP. This was definitely wrong: Telnet is a complex protocol and it requires to answer sever requests according to the specification or no data will be sent at all. Even worse, handshaking can talk place at any time, not only during the first phase.

"OK, let's try to understand how this works".After reading the first part of the specifications, I was no longer really interested to do it on my own ("too complex"). "Why not take an application already available"? What I found were commercial programs which I could not use for some reasons and some free C# programs. The latter helped me to develop this solution (see credits), but had one serious disadvantage for me: they did simply not work with my router.

After digging a little deeper (using the excellent tool Packetyzer) I have figured out the problem: My router uses a lot of cursor movements while sending the data. This means the header is not necessarily send before the footer. If the cursor movements are not properly considered this may lead to wrong interpretations. So a stream oriented approach was doomed to fail in my particular case.

At least it was clear now, how I would attack the problem. I would have to write something which behaves more like a screen rather than a network stream. And this here is the result .....

Last edited Jul 28, 2011 at 2:36 PM by KWB, version 11


No comments yet.