• Please review our updated Terms and Rules here

PCjr Telnet Server Test

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,419
It's running! Telnet to 97.86.233.68 to take a look and help me test it. You can use the standard Windows telnet program, Putty, Linux, or whatever you have handy.

Around 10 users can be on at the same time. When you sign on (no password required) there will be a little menu to help you waste some time. Some things you can do are see who else is on the server, view the machine type, ROM BIOS date and DOS version, check the TCP/IP statistics to see how much traffic it is handling, etc.

There are some upgrades since the last time I ran this test (in Dec 2007):

  • The TCP/IP stack is much better
  • I'm doing 'telnet' negotiation to figure out the terminal type, turn echoing on, etc.
  • Crude line editing has been added

Right now it is running on my PCjr using a Xircom PE3 10BT. I plan to leave it up as long as it runs, or three days, whichever comes first. ;-) It is a PCjr so if there is a momentary delay, don't panic - it's probably just doing disk I/O.

Backspace is a little dodgy .. it really wants ASCII 8 and a lot of terminals and emulators do ASCII 127 instead. Try variations with the shift and control keys if it doesn't work.

Please post comments and bug reports here.

Thanks,
Mike
 
Last edited:
Worked well for me too. A TCP/IP stack on a PC junior. That really is something.

I haven't had a telnet session for a few years now. That really took me back..:)

Tez
 
Works great Mike, quick and responsive. Still a little basic, but hey, it's a PCjr, not a 486!

--Jack
 
I was pleasantly surprised to see everything running this morning - thanks for checking it out!

I haven't looked at the logs yet because they are on the machine being tested, but so far things look good. In the last twelve hours:

Highest number of concurrent sessions: 4
Total sessions: 49

Tcp Pkts Sent 22317
Rcvd 19353
Retrans 34
Seq/Ack errs 364
Dropped 0 (due to lack of TCP buffers)

Pkt stats: Incoming pkts: 19969
Dropped: 0 (due to lack of pkt buffers)
Sent: 22390

The last time I did this test I didn't have telnet option negotiation and I wasn't echoing characters. This time around the number of packets is significantly higher, which is great for testing.

The machine running the test can be seen here:

http://brutman.com/PCjr_WD_small.jpg

That's not the network card it is running on at the moment, but I've used it in previous tests. Right now it's running on a parallel port adapter which gives me about half the throughput of the big Western Digital card. (I don't like the big card hanging out exposed like that for an extended test.)

The machine is fairly vanilla. 640K, Nec V20 CPU, and two parallel ports upgraded to bi-directional. The .EXE file for the code it is running is only around 70KB in size. Total RAM required is probably less than what I used on the IRC client, so it should run in a 256K machine. For a telnet BBS (which is what it will be one day) a 512K or 640K machine will be plenty.

Nobody has alerted me to bad behavior yet and the machine is not on fire, so if you want to pay a visit again to see the packet counts go up, try another telnet client, or try to break it please feel free ...

The address again is: 97.86.233.68



Mike
 
Found my first fatal bug. I think it is fixed and I'd still like to continue testing so come on back and telnet in again!


(The bug was related to handling packet timeouts and retransmits when a TCP connection is first being established. I think I found the bug, which caused stack corruption and killed the program. It's running again with the supposed bug fix, so we'll see ...)
 
Yep, it works.

The first time I cheated and loged in from my regular linux prompt, but then it ocurred to me that minitel.exe ought to work here ... it does! That hasn't worked anywhere for a long time. I guess there's some kind of newfangled authentication on modern servers. BTW, I love that little delay. It reminds me of using 2400 baud (or slower) modems.

Modern equipment that's thousands (or more) times faster often doesn't have any snap ... really bugs me. "You ain't got nothin if you ain't got snap." At least with a Nec V20 there's a legitimate excuse. Minimal is cool. Maximal with low performance is not.
 
It worked fine for me from my XP box. I'm going to try and get my jr up and running with the Xircom adapter I just got off of e-bay..if I can find a long enough cable, lol. If I do, I'll connect using that one too ;)
 
Hello everybody .. it's still going. If you've visited already, then visit again! (And ring the bell with the 'sysop' command) If you haven't visited then what are you waiting for?

Tezza checked in last night from New Zealand. He mentioned that the echo lag was noticable, but the time reported by 'ping' between our two systems was around 380ms. That is nearly 0.4 seconds, which would be quite noticable. On the local network there is no perceptible delay, and within the US the delay is probably reasonable.

The number of TCP packets isn't as high as it was before the crash. People are chatting less, and chatting is what drives the packets up. Ironically, the bug wasn't related to how many packets were coming in, but in the negotiation of a new connection. That code is going to be less thoroughly tested because it does not run anywhere near as often as the normal 'this socket is connected' code. So more connections from different machine types and geographic locations is what I'm looking for.

The Jr says 'bring it on' .. Next time I'm going to have a command that spits out ASCII art of a PCjr. :)

The address once again is: 97.86.233.68 Any telnet client or 'raw' client (netcat on Linux, Putty in RAW mode, etc.) should work, but you might get double echoes if your client insists on local echoing.
 
And it's still running!

So far there have been 177 connections, 52887 TCP packets sent out, 49945 TCP packets received, 176 TCP packets had and to be retransmitted.

At the packet later I had a first ... dropped packets due to a lack of incoming buffer space. out of 53056 incoming packets, 24 were dropped. That must have been one heck of a burst of activity to cause that because in 2 years of working on this I have never seen incoming packets get dropped due to a lack of space to put them. (It might have happened during disk I/O .. it's really slow on this machine.)

Most people are connecting with Windows telnet clients. I have seen OS/2 warp, a client based on WATTCP, an AS/400 in line mode, and even somebody using TOPS-20 (and old PDP-10 operating system).

Keep on coming .. I'm leaving it running until it breaks again. :)
 
Worked fine for me too. Even when using my "ntool" in telnet client mode ;)

By the way, is there a way to send messages to all active users at once,
something like "msg * text" or "broadcast text" ?
If not, wouldn't it be an idea to add something like this ?
 
Ok everybody, one more time .. it's at 60,000+ packets sent and 55,000 packets received. A few more connections with some playing around should put it over 64K on both. Then I'll shut the poor thing off and give it a break. :)


WiWa: Easy enough to do, but this isn't the final code - it's a testbed for the TCP/IP code. I expect a real telnet BBS to have much more function.
 
OK. I just did my bit with a score of connections there. This works out well for me because I'm setting up a new box and it has two telnet clients which I wan't to make sure are working properly including my batchfile setups.

One problem. The NCSA clone (lxtelnet) works properly, and the minitel one by Mark Morley used to. It did yesterday and I haven't changed anything here. Tonight, it hangs on "quit". PCjr just says bye bye and then sits there. What's up with that I wonder?

Not that this matters too much for me anyway. It seems that the DOS clients won't connect to anything anymore anyway... except Mike's. I just keep hoping that some day I'll figure it out. (fat chance!) :(
 
Testing wrapup ...

Testing wrapup ...

After close to 3.5 days of run time I finally shut the PCjr down. Here are the raw stats:

685 sessions (of which about 370 were generated by a script)
TCP packets sent: 93204
TCP packets received: 87367
TCP packets retransmitted: 414
TCP packets dropped due to low buffer space: None

Raw packets sent: 93789
Raw packets received: 92458
Raw packets dropped due to low buffer space: 24​

The first part of the test started Friday night, and the machine crashed early on Saturday afternoon. That was the stack corruption bug exposed by the failed connection attempt with the SYN packets being retransmitted. I had about 70 connections and 40 or 50,000 packets in and out before the crash.

After a quick debug session and some new code I started the test again. The statistics reflect the activity after the restart.

The rate of retransmitted packets is very low, which is good. About one half of one percent of packets (or 1 in 200) needed to be retransmitted. This often occurs when the remote connection drops - my code might try to send a packet, retransmit the packet because there is no response, and then eventually give up. It's also possible that packets were being dropped along the way depending on routers and traffic.

The 'Raw packet' numbers refer to the packet driver. All 24 packets were lost in a 15 minute period while Chuck G. was on the machine experimenting with OS/2 Warp clients. I don't know what caused the hiccup, but it was brutal. Nothing crashed though, and no active sessions were prematurely lost as a result although a few of his sessions seemed to be hung. (I need to find the spot in the very large tcpdump trace where that happened.)

Here are some of the gripes:

  • Backspace (ASCII 8 ) vs. DEL (ASCII 127) - I probably need to accept both
  • User interface issues - sorry, this is a test of my TCP code .. I put the bare minimum up to get it going.
  • Some lag time .. depending on your geographic location it could be very bad. Not much I can do here, except let the code negotiate line mode.

Now on the other hand, I think that everybody who commented on it thought it was the coolest thing. Which really made me feel pretty good about my on and off again three year investment in the TCP/IP code.

I'm going to be reading logs and looking for problems in the traces the next few weeks, and possibly fix a few bugs. I'm also still debating in my head whether the world needs a another Telnet BBS. It's a fun project and it might be worth doing on a small scale, but a big full featured Telnet BBS is a lot of work.

If I do it, I've already started thinking about how to cluster a few Jrs to increase the total number of concurrent online users :)

Thanks for all of the help testing it.

Regards,
Mike
 
mbbrutman said:
I'm debating in my head whether the world needs a another Telnet BBS.
Click to expand...

It doesn't. But what the world DOES need is a nice, tight, resident TCP/IP stack with a programming API, with source code.

I am quite serious in my claim to write a VNC client for oldskool machines if you can make this happen :)
 
mbbrutman said:
[*]Some lag time .. depending on your geographic location it could be very bad. Not much I can do here, except let the code negotiate line mode.
Click to expand...

Actually it wasn't too bad from here Mike. Only a 2-4 character delay in the echo most times. But then I'm not the worlds fastest typist. :)

Great project, well done!

Tez
 
Trixter said:
It doesn't. But what the world DOES need is a nice, tight, resident TCP/IP stack with a programming API, with source code.

I am quite serious in my claim to write a VNC client for oldskool machines if you can make this happen :)
Click to expand...

It might make more sense for somebody to pick up the WATTCP code and to a TSR wrapper for it. That's what I'm going to have to do with my code, and the WATTCP code has the benefit of being more mature. Source code is already available too, and they might have less dependencies on the DOS heap than I do.

(I don't think my code is going to be extremely easy to wrapper. Given my limited time and priorities, I'm probably going for the telnet BBS first.)
 
mbbrutman said:
. . . I'm also still debating in my head whether the world needs a another Telnet BBS. . .
Click to expand...
Well, perhaps the world doesn't need another Telnet BBS
but i could think of other possibly usefull applications for such a project,
provided it ist small enough to fit on a disquette or to co-exist with
other programs in the very limited memory of a DOS system.

1. Add a broadcast, an echo and perhaps some more diagnostic features
to turn it into a tiny tool for testing and debugging TCP/IP nets under DOS.
This might not be terribly new, but still usefull and easy to do.

2. Turn it into a tool that allows to remotly control a DOS box via Telnet.
To do this, the program would have to be able to go resident as TSR
and hook into the timer interrupt, to regularly watch for incoming data.
Any text coming from the remote client would have to be fed into the keyboard buffer
and any changement on the screen (or the video buffer),
should be comunicated back to the remote end.

This would definitely be a much more ambitious project,
but i personally only know of one such program up to now,
one which doesn't work satisfacturely,
so one could really gain merrits in this domain.
 
You must log in or register to reply here.
Back
Top