Multiple telnet connections

[ckoehler]

Hi,

Is it possible to have two telnet connections, say one on port 23, one on 24?
The one on 23 would be mostly write only, maybe rw, but the one on 24 would be strictly read-only; it would only dump out data for another box to evaluate.

How would I code that if I already have one connection working, and how would I keep the code sufficiently separate to be able to maintain it more easily? Right now I have a static class that handles all the port 23 stuff, and I would like to have another one that handles the port 24.

Would there be conflicts between the two, like one seeing the input or output of the other? Does it require an extra serial port or could I theoretically open lots of sockets on different ports for clients to connect to? It's possible on a desktop machine, so it should work just fine.

Thanks!

Christoph

[tod]

Yes, you can have many (the limit is probably around 32 - I'm not sure but resources are limited) ports open. I avoid calling them "Telnet" ports, you're just opening ethernet sockets connections. You get seperate file descriptors for each socket so its not an issue having cross talk. I'm not a big fan of static classes (and this is one reason why). If I want singleton behavior out of a class I usually have a factory wrapper that works like this:

Code: Select all

ServiceProvider::GetTcpServerAsSingleton();

Which is returning a static instance of the TcpServer class (much different than a static class). Then if I want a different instance I can just create a new one.

Code: Select all

TcpServer secondTcpServer;
secondTcpServer.SetTcpListenPort(newPortNumber);

[rnixon]

I think you get 32 ports maximum. Listening ports still count as ports, so you need to account for the web server http port, telnet listening port, etc.

[ckoehler]

Thanks guys,

What are the difference between "telnet" and sockets? Not technically, but in the NB API? Do I still have to use the command processor, set CmdConnect_func, etc, do CmdListenOnTcpPort, and stuff?

And if I just want to dump data to the client that connects, a simple socket should be enough, right?

Thanks!

Christoph

[tod]

Correct, you can set up sockets using the std listen/accept loop. Then you can use the returned file descriptor however you want. No need to go through a username/password step to connect either. The client software can just connect on the designated port and start connecting. You aren't limited to using the traditional TelNet port of 23 either.

I'm not that familiar with the code from the TelNet example but it looks like they wrapped some lower level stuff and also give you some additional functionality for parsing etc. If you don't want/need any of that you don't have to use it.

[rnixon]

Normally a telnet connection has some type of command syntax. The command stuff you are referring to is an example of how to implement that. If you don't need a command parser, or are more comfortable with a switch statement, then just use a tcp connection. Technically there is more stuff like buffering that goes on in a telnet connection, but for what you are doing it shouldn't matter.

[ckoehler]

Aah ok, thanks, starting to wrap my head around this.
If I wanted to use some basic commands (say authentication) and make use of the command processor, any idea how I would do that? Didn't think about that before, but it may be needed.

Thanks!

Christoph

[Chris Ruff]

I am not sure what you mean by "command processor", but generally, all Telnet is is a listener on port 23 on the server and a client connecting to the server on port 23. The data that travels back and forth is usually a text-based protocol, usually simple.

The server-side Telnet listener socket hands the incoming client connection off to some socket and the client socket and the new server socket rattle data back and forth for the life of the Telnet connection.

So, leaving the word "Telnet" behind -> what you want is a couple listeners on the server listening on "well-known" (to your system) ports.

the Data itself can be AES-encrypted with all of the private key and public key algorithms. 's up to you.

Another thing you will need to decide is how many clients will be allowed on each "daemon" (the Listener task) on the server. You may choose to only allow one or as many as 8. still up to you.

If you only want one connection at a time you can accept the 2nd client, open the socket session, send a NAK and immediately drop the client.

easy.
fun.

the NetBurner way...!