PDA

View Full Version : Another DOS IRC Client



mbbrutman
May 12th, 2008, 06:48 PM
Well, that long rambler of a post didn't get me anywhere. :-)

Anyway, I'm pretty happy. I started an IRC client tonight and had it running and talking in less than an hour. It's not pretty but it works ..

I was thinking of doing a very simple user interface for it:


3 lines at the bottom of the screen for entering your message
The rest of the screen for incoming messages
Only one window .. if you join multiple channels all of the conversations will be interleaved. (I could color code them.)
No file transfers or anything like that .. just plain old chat.


Thoughts?

Trixter
May 12th, 2008, 11:07 PM
3 lines at the bottom of the screen for entering your message
The rest of the screen for incoming messages
Only one window .. if you join multiple channels all of the conversations will be interleaved. (I could color code them.)
No file transfers or anything like that .. just plain old chat.




I would have only one line at the bottom for entering a message, and have that line scroll horizontally if the user tries to go off the line. This is how the "good old clients" of yesteryear worked in text mode. Maybe a separator line above that to denote which is you and which is the channel, but that's it. The more lines for channel text, the better :)

I would not have all channels in a single window because, while reading could be color-coded, how would you specify which channel you were replying to? I would instead keep track of multiple channels simply by letting the user hit a key combo to switch to a completely different screen; or, maybe implement split-screen. I would consult console IRC clients to see how they do it.

I am available for testing :)

mbbrutman
May 13th, 2008, 03:54 AM
I'm trying to keep it really simple because I don't have a lot of time for this. The horizontal scrolling for long input is neat, but that will require something more sophisticated than what I had in mind. (I hate tracking cursors and going screen work.)

Good catch on the problem with replying when multiple channels. Switching to a different screen works for CGA, but not mono. I could prefix everything with a tag, but that is a PITA. Or I could just limit to one channel per client and then it becomes the users's responsbility to pay attention to that channel. :-) Do people actually try to monitor and interact with multiple channels?

I really don't want a full blown MIRC clone. Just something to use the XT at work for which will keep people amused.

dongfeng
May 13th, 2008, 05:09 AM
Working on mono would be great, then I could use it on my 5150 ;)

Other than that, it sounds like you have things thought out well already!

(Colour coding on a CGA/EGA would be a huge benefit)

Half-Saint
May 13th, 2008, 05:31 AM
Try ircii for ideas on how to solve some of your problems :)

Cheers!

Trixter
May 13th, 2008, 01:24 PM
I'm trying to keep it really simple because I don't have a lot of time for this. The horizontal scrolling for long input is neat, but that will require something more sophisticated than what I had in mind. (I hate tracking cursors and going screen work.)


Well, you're going to be doing screen handling anyway; see below:


Good catch on the problem with replying when multiple channels. Switching to a different screen works for CGA, but not mono.

You don't actually maintain separate windows in video ram for all channels; when you "switch" you just repaint the screen for the current channel and start updating. You'll be maintaining a buffer history anyway so this shouldn't be difficult.



I could prefix everything with a tag, but that is a PITA. Or I could just limit to one channel per client and then it becomes the users's responsbility to pay attention to that channel. :-) Do people actually try to monitor and interact with multiple channels?


All the time. I would display the name of the channel and other info in the "separator bar" above the bottom input line.



I really don't want a full blown MIRC clone. Just something to use the XT at work for which will keep people amused.

Actually, IRC clients are one way to ensure that XTs stick around forever. Most people join a channel and then wait for people to say something interesting; if your client has an option to beep on every new message, it would be mega-frigging-cool, just like the old BBS days -- people could be working on whatever they want and then swivel over to the XT to talk a bit, then go back to what they were doing.

Not that I'm drooling at the mouth waiting for it or anything. ;)

mbbrutman
May 13th, 2008, 01:30 PM
I'm conflicted. I want to throw the current version out there right now just to get the TCP stack exercised, but the user interface is, shall we say, substandard .. I probably need to exercise some patience and do a proper UI.

What I described before will work for a first version, and as a matter of practicality it will probably only support one active channel. Another version can add the multiple channel support.

The nice thing about IRC is that it is just *so* easy compared to the code I've been doing. The nasty thing about all of this is the screen handling.


Mike

Mike Chambers
May 14th, 2008, 12:45 AM
hey mike, if you have time i'd love for you to send me a binary and source for your client. did you write it in the same flavor of C that you mailed me disks for?

i'd love to take a look at it.

i still think you should throw in some drop-down menus and DCC file transfer capability. it comes in really handy on my old machines, i can sit there on a server chatting with folks in leetIRC while at the same time copying some files to it from an XP box. of course, being a QB program handling both chatting and file transfer at the same time on like an XT is less than speedy, but hey that just leaves me more time to chat! lol. (it's pretty bad, if i'm actively chatting while downloading in it i get 3 KB/s if i'm lucky) if i disconnect from the server after initiating the transfer, that frees up some CPU by not doing any of the TCP calls to check for incoming data in the buffer and it bumps it up to around 6 or 7.)

DCC file code is simple, like i was telling you the other day. if you want the details let me know i'll give you the info. not much to it.

btw, if the version of leetirc you tried way back in 2006 was one of the dinky pre-release/testing version i HIGHLY reccommend you download and try out my version 1.1!! http://rubbermallet.org/download/lirc11.zip

it comes with both the source and binary. if you try it, make sure you play around with the menus and be sure to check out the server list dialog box.

it might give you some ideas for your client. if you can't tell by now, i'm proud of my little QB proggie hah. (with good reason if you compare it to most of the other DOS IRC clients out there)

mbbrutman
May 14th, 2008, 06:42 PM
I ran it today at work all day long. The channel I was on did not get a lot of traffic, but it survived being up for multiple hours with no problems.

I should be able to get a usable binary out in a week or two. Right now things like my name and nickname are hardcoded, which was cheap and easy for getting started but not very good for distributing to other people. ;-0

I don't intend on shipping the source code for the TCP library any time soon. It is currently at 5400 lines of code, and it's a significant investment for me. I will eventually ship it as a set of binary libraries and header files. The libraries will consist of the TCP code with different options enabled/disabled. For example, one version of the library will be pretty stripped with a small amount of buffer space, minimal tracing, etc. That version will be suitable for very small machines. A full blown version of the library will have every bell and whistle, but will be a much larger binary. (40 to 50KB vs. 25 to 35KB). Turbo C++ users can readily use the libraries, so it will not be an issue.

I'm not really too interested in the DCC feature. I've got a good version of netcat for transfering files/data already, and a good FTP client makes more sense. It can easily be done, but it's not high on my feature list. Keeping it fast enough to use on a PCjr or XT is the primary goal.

I've downloaded LeetIRC again and I'll revisit it tomorrow .. but before I do, is there any hope of it running well on an XT or do I need something faster?

Mike Chambers
May 16th, 2008, 12:50 AM
I ran it today at work all day long. The channel I was on did not get a lot of traffic, but it survived being up for multiple hours with no problems.

I should be able to get a usable binary out in a week or two. Right now things like my name and nickname are hardcoded, which was cheap and easy for getting started but not very good for distributing to other people. ;-0

I don't intend on shipping the source code for the TCP library any time soon. It is currently at 5400 lines of code, and it's a significant investment for me. I will eventually ship it as a set of binary libraries and header files. The libraries will consist of the TCP code with different options enabled/disabled. For example, one version of the library will be pretty stripped with a small amount of buffer space, minimal tracing, etc. That version will be suitable for very small machines. A full blown version of the library will have every bell and whistle, but will be a much larger binary. (40 to 50KB vs. 25 to 35KB). Turbo C++ users can readily use the libraries, so it will not be an issue.

I'm not really too interested in the DCC feature. I've got a good version of netcat for transfering files/data already, and a good FTP client makes more sense. It can easily be done, but it's not high on my feature list. Keeping it fast enough to use on a PCjr or XT is the primary goal.

I've downloaded LeetIRC again and I'll revisit it tomorrow .. but before I do, is there any hope of it running well on an XT or do I need something faster?

ah, gotcha. not going the open-source route eh? i don't blame you, i know you've been writing this for over a year now.

and yeah, and XT should be fine for leetIRC. when i complained about it in the past, i didn't realize that somehow it was the VGA card i have that was causing it to run very slow. i don't know why it does it, but it runs great on an 8088 with the mono card installed. other people have reported it's fast with their VGA cards in their XT's.

(the speed issue with that card is not just with an XT. same thing if i put it in my other XT "turbo" clone or a 286. i also know it's not a problem with my software. same thing with games, and even just watching a directory listing scroll the screen from a DIR command)

dongfeng
May 16th, 2008, 04:54 AM
I've ran LeetIRC on my XT with no problems. It's a bit slow in heavy channels, but otherwise great. It even runs on my 5150 with 5151 through a Hercules card (using HGCIBM) :)

mbbrutman
May 16th, 2008, 07:00 AM
ah, gotcha. not going the open-source route eh? i don't blame you, i know you've been writing this for over a year now.


I haven't decided against open-source. But I have decided against open-source today.


It's not fully functional yet
It is somewhat tested, but not heavily tested
The pool of people who can actually get the development environment and collaborate with me is very small
The documentation is too thin for other people to go making changes

Trixter
May 16th, 2008, 06:01 PM
The nice thing about IRC is that it is just *so* easy compared to the code I've been doing. The nasty thing about all of this is the screen handling.


You've written a TCP/IP stack from scratch, figured out how to dump PCjr ROMs, hacked an ISA bus onto your PCjr, and you're complaining about the SCREEN HANDLING of all things? Seriously? Compared to those prior efforts, screen handling is easy! :mrgreen:

Seriously, if you need help with screen handling, I've written more screen routines than I'd like to imagine. Ask away.

Trixter
May 16th, 2008, 06:02 PM
I've ran LeetIRC on my XT with no problems. It's a bit slow in heavy channels, but otherwise great. It even runs on my 5150 with 5151 through a Hercules card (using HGCIBM) :)

While I love the program and concept, it's too slow for me on real 4.77MHz 8088. The screen updating is fine but I can type faster than the program will take my keystrokes, which leads to keyboard buffer overflows.

Trixter
May 16th, 2008, 06:22 PM
(the speed issue with that card is not just with an XT. same thing if i put it in my other XT "turbo" clone or a 286. i also know it's not a problem with my software. same thing with games, and even just watching a directory listing scroll the screen from a DIR command)

Hm... well, that would imply that you're using the BIOS for screen writes. Let me try using LeetIRC with both BIOS screen stuff and with NNANSI BIOS replacement (speeds up BIOS screen handling 5-15x)...

Just running it again on CGA proves it's not using the BIOS as I seen screen snow. And it is pretty damn slow.

I'm not knocking your programming skills... I'm knocking your compiler.

The only thing that is really killing it is the screen scrolling. It takes at least 2 seconds to scroll. Looking at your code, I see that DrawScr is the culprit:



drawloc = 22
DEF SEG = &HB800
ScrChanged = 0
FOR y = bufstart + 20 TO bufstart STEP -1
tmpline$ = LEFT$(Buffer(y), 158)
curpos = (drawloc * 160)
FOR tmpval = 1 TO 158
POKE curpos + tmpval - 1, ASC(MID$(tmpline$, tmpval, 1))
NEXT tmpval
drawloc = drawloc - 1
NEXT y


If you or anyone else who is a guru with BASIC can figure out how to speed this up, the program would be usable on 5150/5160 w/CGA.

mbbrutman
May 16th, 2008, 07:45 PM
You've written a TCP/IP stack from scratch, figured out how to dump PCjr ROMs, hacked an ISA bus onto your PCjr, and you're complaining about the SCREEN HANDLING of all things? Seriously? Compared to those prior efforts, screen handling is easy! :mrgreen:

Seriously, if you need help with screen handling, I've written more screen routines than I'd like to imagine. Ask away.

Eh, I can do it. You've wisely called me out on my sandbagging. ;-)

Mike Chambers
May 17th, 2008, 07:47 AM
I've ran LeetIRC on my XT with no problems. It's a bit slow in heavy channels, but otherwise great. It even runs on my 5150 with 5151 through a Hercules card (using HGCIBM) :)

yeah, i don't know what the deal with my card is. i'm going to take a video of it updating the screen as new messages come in, it's really bad. i'll do it with a monochrome card too so i can demonstrate how big of a difference there is.

Mike Chambers
May 17th, 2008, 08:26 AM
Hm... well, that would imply that you're using the BIOS for screen writes. Let me try using LeetIRC with both BIOS screen stuff and with NNANSI BIOS replacement (speeds up BIOS screen handling 5-15x)...

Just running it again on CGA proves it's not using the BIOS as I seen screen snow. And it is pretty damn slow.

I'm not knocking your programming skills... I'm knocking your compiler.

The only thing that is really killing it is the screen scrolling. It takes at least 2 seconds to scroll. Looking at your code, I see that DrawScr is the culprit:



drawloc = 22
DEF SEG = &HB800
ScrChanged = 0
FOR y = bufstart + 20 TO bufstart STEP -1
tmpline$ = LEFT$(Buffer(y), 158)
curpos = (drawloc * 160)
FOR tmpval = 1 TO 158
POKE curpos + tmpval - 1, ASC(MID$(tmpline$, tmpval, 1))
NEXT tmpval
drawloc = drawloc - 1
NEXT y


If you or anyone else who is a guru with BASIC can figure out how to speed this up, the program would be usable on 5150/5160 w/CGA.

i'm actually in the process of doing a little experiment with that. what i'm trying to do is have QB code actually "compile" some raw machine code. i'll dynamically create a string based on the return values of VARSEG and VARPTR and have it move "x" amount of bytes to the proper position in video memory from where QB stores it. i hope i can get this program to run fast like that. i know just enough x86 ASM to pull that off i think. :p

i'm planning to majorly update LeetIRC with the ASM method of screen writing, along with having a DNS resolution routine so you don't have to run across the house to another computer with a pen and paper to ping the hostname (that will be nice lol) and an option for DCC send in addition to the receive that's already there. (possibly DCC chat if i feel adventurous, but probably not. does anybody actually even use that??) there will also be a built-in identd server.

that about sums up my goals for v1.2, and i'll probably stop work on it after that i can't really think of anything else i would/could need in an IRC client.

mbbrutman
May 26th, 2008, 08:08 PM
Well, I took a stab at the screen I/O. It's a PITA. Here is what I have so far:


21 lines of chat area
1 separator line: Will eventually hold some status
3 lines of input: The only editing supported in the input area is backspace.


Turbo C++ provides some high level routines for managing an active window and moving text around. The routines are tolerable for typing - I type 100wpm and I can't overrun the keyboard. The routines are not so great for scrolling the chat area, so I wrote my own based on memory moves. It runs great on a 4.77Mhz machine, so there will be no performance issues.

What I've got now looks slightly better than what I had, but the code is an unholy mess. I need to take a week or two and clean things up. Also, I'm not doing a great job of parsing the incoming messages from the server, so the screen fills up with the detail of the messages that most IRC clients know to filter out. When I get things cleaned up I'll post a copy for people to pound on.

Mike

mbbrutman
June 1st, 2008, 06:27 PM
Ok, I've got a test version ready!


http://brutman.com/Dos_Networking/software.html

There is a zip file with the application and a readme on that page. Give it a whirl and let me know what you think!

General DOS Networking help can be found here:


http://brutman.com/Dos_Networking/

Support will be provided here and by email (mbbrutman@yahoo.com) if you need it. And of course on the #vc IRC channel on Gimp. (irc.us.gimp.net)

-Mike

Trixter
June 1st, 2008, 08:30 PM
It's a resounding success, with the exception that it decides to just quit on me, as if I had exited manually. This last time it exited, I was in the middle of typing a reply:



irc.gimp.ca 401 _Trixter_ This :No such nick/channel
brut_pcjr PRIVMSG #vc :You don't need to enter a command to send a msg, unless y
ou really want a private message.
brut_pcjr PRIVMSG #vc :Try this:
brut_pcjr PRIVMSG #vc : /privmsg brut_pcjr :msg goes here
_Trixter_: Okay, so this message is public...
_Trixter_: /privmsg brut_pcjr ...and this message is private
brut_pcjr PRIVMSG #vc :Yep - by default everything goes to the channel that you
last joined.
brut_pcjr PRIVMSG #vc :Just type and it will go to the channel. True 'private m
essages' will come later.
_Trixter_: Every message I'm seeing says PRIVMSG #vc :..... so I can't tell if t
hese are private or public
컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴
But, display issues aside, I Irc Stats: Ping Responses: 0
Tcp Pkts Sent 39 Rcvd 37 Retrans 6 Seq/Ack errs 0 Dropped 0
Pkt stats: Incoming pkts: 296 Dropped: 7 Sent: 48
LowFreeBufferCount: 0

c:\internet\brutirc>


You can see me type "But, display issues aside, I " before it craps out.

Spurious keyboard interrupt? Is that an error output?

Display speed is fantastic, btw. I am curious how your "snow value" works (ie. higher numbers = less snow) but I'll respond to the snow discussion in the other thread first.

mbbrutman
June 1st, 2008, 08:39 PM
Well, come on back and try it again ..

I have no idea what caused the spontaneous death - it hasn't happened to me yet. Ctrl-X will do it.

I did notice from the ending statistics that your packet driver dropped some of the incoming packets because it ran out of buffer room. I'm curious about that - what card, which packet driver, and did you purposefully hit Pause or something to delay it for a while?

(There are 20 receive buffers for the packet driver, and I've never seen more than 5 used. You used all 20.)

mbbrutman
June 2nd, 2008, 06:51 PM
New version posted yesterday with the following features:


Added filtering of gorp from the server on messages to and from users
Added easier way to send private messages (/msg)
Added a toggleable beeper for new incoming messages


Mike

Trixter
June 2nd, 2008, 06:58 PM
Well, come on back and try it again ..

I have no idea what caused the spontaneous death - it hasn't happened to me yet. Ctrl-X will do it.


Yet I didn't hit ctrl-x :)



I did notice from the ending statistics that your packet driver dropped some of the incoming packets because it ran out of buffer room. I'm curious about that - what card, which packet driver, and did you purposefully hit Pause or something to delay it for a while?


Nope. Was just typing. I am using an Intel Etherexpress 8/16 (in 8-bit mode of course).

Keep in mind you have probably used slow packet devices (xircom) on slow machines, and fast devices on fast machines. But I am using a fast device (can do 40KB/s) on a slow machine (XT). Might that have had something to do with it?

Can you double the number of receive buffers to 40? @ 1500 that would still be under 64K...

Trixter
June 2nd, 2008, 07:22 PM
New version posted yesterday with the following features:


Added filtering of gorp from the server on messages to and from users
Added easier way to send private messages (/msg)
Added a toggleable beeper for new incoming messages


Mike

Well, it dropped in the middle of typing something again :-(
I was typing "Me, I have CGA snow set " and it existed to DOS.
Here's the session, thanks to SNIPPER.COM (loaded AFTER the drop):



<_Trixter_> /msg brut386 although it looks like my messages are going public whe
n I do this
<brut386 to _Trixter_> Yep .. private messages.
<_Trixter_> /msg brut386 Ah, I see reverse video when receiving private but not
when sending... add that to the todo list:)
<_Trixter_> This is really fantastic. This is already part of my arsenal.
<brut386 to _Trixter_> And for my friends with mono, the explicit "to" word
<_Trixter_> /msg brut386 well, mono friends have regular, bright, and reverse, b
ut it is still appreciated
컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴
Me, I have CGA snow set Irc Stats: Ping Responses: 0
Tcp Pkts Sent 26 Rcvd 24 Retrans 8 Seq/Ack errs 0 Dropped 0
Pkt stats: Incoming pkts: 245 Dropped: 23 Sent: 38
LowFreeBufferCount: 0

Please send comments and bug reports to mbbrutman@yahoo.com


c:\internet\brutirc>


Is this a normal exit, as if I had requested the exit through ctrl-x? Because I definitely didn't hit that, so you may want to check for alternate ways the "exit" signal/command/whatever is getting through. If it's an error out then maybe some indication of the error...?

mbbrutman
June 2nd, 2008, 08:26 PM
You are definitely having comm problems there. Here is the giveaway:


Tcp Pkts Sent 26 Rcvd 24 Retrans 8 Seq/Ack errs 0 Dropped 0
Pkt stats: Incoming pkts: 245 Dropped: 23 Sent: 38
LowFreeBufferCount: 0

That tells me that you had a very short session (just 24 packets received from the IRC server), and it probably ended in error when a packet timed out and was retried a few times. Interesting, on the raw Ethernet you had 245 packets inbound, but only 38 outbound - there must be a metric buttload of broadcast traffic on your home network.

You definitely ran out of incoming buffer space for Ethernet frames, most of which were being tossed away anyway. But what killed you was a packet that you tried to send - my TCP stack will retry a packet six times before giving up and killing the connection.

The main loop exits when you hit Ctrl-X or when the server side closes the connection. I just added an error message for the remote connection being closed and tested it by yanking a cable. If you plug the cable back in quick enough the retry mechanism will save the connection, but after six retries it gives up. You had a combined total of 8 retries, so it probably recovered from a few dropped packets before things got hopelessly out of sync.

Here's the fun part ..

set debugging=255
set logfile=irc.log

That's going to generate a log file with a lot of stuff in it. It will be painful. It will still run on your XT or PC, but you will notice the hard drive exercising quite a bit. That log will help me diagnose exactly what caused the sequence of events that resulted in the dropped connection.

Also, do you have any TSRs that might be hogging the CPU? Every idle loop in my program checks for data that the Ethernet card dropped in the buffers, and pushes the data through the stack. I don't have anything that can cause such a delay that the buffer gets overrun, unless you are carpet bombing that PC with packets. (And even then, I know the machine can keep up with a stream of 40KB per second or so.) If you have a TSR that comes to the foreground and stops my app for a few seconds or more, then this could happen.

I can give you a debug copy that increases the incoming buffers to something like 40 or 100, and also cuts the mtu size down to 500 or so. For IRC packet size is never more than 512 bytes anyway, so a smaller MTU would work.

BTW, I had it online all day today from my office on the XT. Close to 1000 TCP/IP packets in and out, and 1200 Ethernet frames in (1000 or so out).

Trixter
June 2nd, 2008, 08:37 PM
You definitely ran out of incoming buffer space for Ethernet frames, most of which were being tossed away anyway.


I have a very busy network. But should that be a reason for this to happen? The NCSA stack doesn't have a problem with this, for example, nor wattcp.



after six retries it gives up


What does the RFC say about retries? How many times?



That log will help me diagnose exactly what caused the sequence of events that resulted in the dropped connection.


I died again, so here's the fun part of that log:



23:31:35 Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01 ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 62 33 29 DE ........b3).

23:31:35 Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01 ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 62 33 29 DE ........b3).

23:31:35 Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01 ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 62 33 29 DE ........b3).

23:31:35 W Tcp: (2e980004) Retrans, SEQ=1f1e7afd ACK=5314568d
23:31:35 Tcp: (2e980004) Send (2eaa0bfc) ESTABLISHED Len: 70 Win=10240 Tries: 7
23:31:35 Packet layer: Sending 124 bytes, dumping 124
00 16 B6 DA A3 77 00 AA 00 6F CF 6D 08 00 45 00 .....w...o.m..E.
00 6E 00 00 40 00 FF 06 DD FC C0 A8 47 58 82 EF .n..@.......GX..
12 9D 14 82 1A 0B 1F 1E 7A FD 53 14 56 8D 50 10 ........z.S.V.P.
28 00 9F 5B 00 00 50 52 49 56 4D 53 47 20 23 76 (..[..PRIVMSG #v
63 20 3A 45 76 65 72 79 6F 6E 65 20 69 67 6E 6F c :Everyone igno
72 65 20 6D 65 2C 20 49 27 6D 20 67 6F 69 6E 67 re me, I'm going
20 74 6F 20 73 65 6E 64 20 61 20 66 65 77 20 62 to send a few b
6F 67 75 73 20 6C 69 6E 65 73 0A 0A ogus lines..

23:31:36 Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01 ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 62 33 29 DE ........b3).

23:31:36 W Tcp: (2e980004) Timeout SEQ=fd7a1e1f ACK=8d561453
23:31:36 Tcp: (2e980004) destroy
23:31:36 W Tcp: (2e980004) Tried recv in state CLOSED
23:31:36 W Tcp: (2e980004) Tried to send a packet while in CLOSED
23:31:36 Tcp: (2e980004) shutdown( 0 )
23:31:36 Tcp: (2e980004) close called
23:31:36 W Tcp: -CC- Socket (2e980004) found 0 in lists
23:31:36 Tcp: (2e980004) closeLocal: socket state=CLOSED
23:31:36 Tcp: (2e980004) closeLocal: socket state now=CLOSED
23:31:36 Tcp: (2e980004) destroy
23:31:36 W Tcp: -CC- Socket (2e980004) found 0 in lists
23:31:36 Tcp: (2e980004) returned to free list
23:31:36 PACKET.CPP: Handle released




Also, do you have any TSRs that might be hogging the CPU?


Nope :-) Just a busy network.

Trixter
June 2nd, 2008, 10:09 PM
BTW, I had it online all day today from my office on the XT. Close to 1000 TCP/IP packets in and out, and 1200 Ethernet frames in (1000 or so out).

What ethernet card were you using?

mbbrutman
June 3rd, 2008, 06:23 AM
I think I've got the bug. I love trace files ...

As the log shows, it died trying to send that packet. On the 7th retransmit it failed.

The real clue is the incoming packets before:


23:31:35 Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01 ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 62 33 29 DE ........b3).

I've been looking at that packet trying to figure out what the hell it is. It's not ARP and its not IP. IP would have 0800 in bytes 13 and 14, and ARP would have 0806 in those bytes. You have 00 06 so that tells me it is Ethernet 802.3, and it is actually a length field not a protocol type.

My bug is that when I get a packet type I don't understand I'm not discarding the packet - that will be fixed as soon as I get home. That bug has been in my code for at least 1.5 years! It also explains why you are running out of incoming buffer space ... after you get 20 such buffers you can't receiving any more packets, and that means that you can't receive ACKs for previously sent packets either. Hence the retries and eventual death.

Bravo! It will be fixed tonight ...

Can you confirm that you are running 802.3 and Ethernet II on the same subnet? I don't do this, which is why it always works for me ...

Trixter
June 3rd, 2008, 08:37 AM
I've been looking at that packet trying to figure out what the hell it is. It's not ARP and its not IP. IP would have 0800 in bytes 13 and 14, and ARP would have 0806 in those bytes. You have 00 06 so that tells me it is Ethernet 802.3, and it is actually a length field not a protocol type.


Can you be more specific on "802.3"? There are a bazillion different variants (I'm assuming you mean something here: http://en.wikipedia.org/wiki/IEEE_802.3 )



My bug is that when I get a packet type I don't understand I'm not discarding the packet


Oh, well, heck yeah that's what it is :-)



Can you confirm that you are running 802.3 and Ethernet II on the same subnet? I don't do this, which is why it always works for me ...

Only if you can confirm what you mean by 802.3 :-)

The protocols I can think of that float around my network are TCP, UDP, ICMP, netbios, WDS (although that shouldn't be on the internal LAN)...

If I could figure out how to craft that data into something parsable by wireshark, we could let wireshark tell us...

Mike Chambers
June 3rd, 2008, 09:41 AM
Ok, I've got a test version ready!


http://brutman.com/Dos_Networking/software.html

There is a zip file with the application and a readme on that page. Give it a whirl and let me know what you think!

General DOS Networking help can be found here:


http://brutman.com/Dos_Networking/

Support will be provided here and by email (mbbrutman@yahoo.com) if you need it. And of course on the #vc IRC channel on Gimp. (irc.us.gimp.net)

-Mike

my name is-a borat, i like-a you IRC client. is niiiiiice.

seems to work just fine. i only tried it under DOSBox so far. i have to go run some errands, but when i get back i am going to boot up the XT clone and copy your client over to it using the DOS FTP server i've been programming for the past couple days.

i'm curious to see how quick it runs on that machine. one thing i would try to do though, is just use one line at the bottom for text input. it would give more room to put the incoming data on the screen.

and also i haven't checked yet, but does the program let you scroll back and forth through the log? that kind of functionality is not necessarily required, but in LeetIRC i have 1000 lines allocated for buffer scrolling. it is very nice to have, say you've been out of the room for a while you can scroll back up to see if you missed anything. kinda cool to have, and comes in very handy sometimes.

http://rubbermallet.org/mikebirc.png

mbbrutman
June 3rd, 2008, 09:43 AM
I may have had it backwards, but from here is the relevant paragraph from that web page:


What is defined in earlier IEEE 802.3 standards is often confused for what is used in practice: most network frames you will find on an Ethernet will be DIX frames, since the Internet protocol suite will use this format, with the type field set to the corresponding IETF protocol type. IEEE 802.3x-1997 allows the 16-bit field after the MAC addresses to be used as a type field or a length field, so that DIX frames are also valid 802.3 frames in 802.3x-1997 and later versions of the IEEE 802.3 Ethernet standard.

My code assumes DIX frames, where the two bytes after the MAC addresses identify the protocol. Older 802.3 frames have a length field there instead, and then use 8 bytes for LLN/SNAP to identify the protocol.

There was a split at 802.3 and DIX. The split is reconciled again at 802.3x - look at the chart ...

Mike Chambers
June 3rd, 2008, 11:51 AM
mike b: question. when you were writing your TCP/IP stack, was packet driver communication basically done the same way my code communicates with TCPDRV? just software interrupt calls?

i know it's more complicated than my code talking to TCPDRV, since you have to handle packet framing and everything.

Mike Chambers
June 3rd, 2008, 12:46 PM
ok mike, i just wanted to let you know i ran it on my XT clone with an IBM monochrome card. i remember you were asking about it on mono in the readme file.

it works great on it, and it's very fast. good job!

two thumbs up! :thumbsup::thumbsup:

mbbrutman
June 3rd, 2008, 05:27 PM
Hi everybody. Work got in the way today - I hate it when that happens.

Anyway, I posted a new version with the big bug fixed. I'm so happy that the trace was detailed enough to lead to the bug - that is exactly what the point of a trace is. Trixter, you should be able to run more than two minutes now. It would be fun to see what's running on your network with the non-DIX frames. Old versions of Novell maybe?

Mike C: I had not tested at all on a monochrome screen, so it is good to hear that it works. The theory of operation is the same, but my color selection is obviously a lot more limited. The rest of the screen handling is the same. There is no backscroll buffer yet.

Communication with the packet driver is through a software interrupt mechanism, which is very similar to what you do when you talk to the Trumpet TCP/IP TSR.

For receiving packets from the packet driver you have to provide a function for it to call. There is some ambiguity in the spec as to how one is supposed to code the return from the function.

All of the Crynwr packet drivers and their derivatives are 'good' in that they return the way you would expect (and the way the compiler generates the code). The Xircom PE3 10BT (which I use on the PCjr) has a crappy packet driver that does something nasty that caused me all sorts of grief. I can't remember the details now, but basically I had to write my own assembly code to replace the compiler generated code that does the return, so that the packet driver wouldn't blow up. I had quite a few emails back and forth with Russ Nelson (the force behind the packet driver specification) to understand the problem and work around it. Once I was able to send and receive raw Ethernet frames, the rest was just a simple matter of programming. (Ha!)

See here for the details on the packet spec:


http://www.crynwr.com/packet_driver.html


Mike

Mike Chambers
June 3rd, 2008, 07:30 PM
thanks for the packet driver spec link, i am way ahead of you though.. i already printed that doc out last night and i have it sitting here stapled all nice and neat. :p

i was going to play around with it.

mbbrutman
June 3rd, 2008, 07:40 PM
Actually, I'm about 2.5 years ahead of you with regards to having printed it out and coding to it. ;-0

Trixter
June 3rd, 2008, 07:55 PM
Anyway, I posted a new version with the big bug fixed. I'm so happy that the trace was detailed enough to lead to the bug - that is exactly what the point of a trace is. Trixter, you should be able to run more than two minutes now. It would be fun to see what's running on your network with the non-DIX frames. Old versions of Novell maybe?


Oh hardy har har. :-) I am working on work tonight :-( but I will do a dump of my network and look for those 60-byte packets and see if I can identify what they are. They're probably netbios.

Mike Chambers
June 3rd, 2008, 08:04 PM
Actually, I'm about 2.5 years ahead of you with regards to having printed it out and coding to it. ;-0

yeah, you win. i don't really plan to make my own TCP stack... at least not right now, and for SURE not in QB. i like transfer rates OVER 1 kB/s :o

i was just going to screw with it a bit... maybe make a packet sniffer and watch my network go crazy or something, i dunno.

mbbrutman
June 15th, 2008, 08:21 PM
Trixter - what were those funny packets?

In other news ... I've added support for a backscroll buffer. It looks like I did a pretty good job with the TCP stack because you can continue receiving data from the other side even while looking at the backscroll buffer. The incoming data just gets buffered, and if buffer space runs out the TCP stack reports a 'zero window' condition correctly to the server side. And it also responds correctly to 'zero window probes.

(Translation for normal people - you can sit all day looking at the backscroll buffer and even though data might stop flowing after the buffer space runs out, the connection won't error out.)

I'll have another version out for download in a few days. After that, what else are people interested in?


Mike

Mike Chambers
June 15th, 2008, 09:15 PM
Trixter - what were those funny packets?

In other news ... I've added support for a backscroll buffer. It looks like I did a pretty good job with the TCP stack because you can continue receiving data from the other side even while looking at the backscroll buffer. The incoming data just gets buffered, and if buffer space runs out the TCP stack reports a 'zero window' condition correctly to the server side. And it also responds correctly to 'zero window probes.

(Translation for normal people - you can sit all day looking at the backscroll buffer and even though data might stop flowing after the buffer space runs out, the connection won't error out.)

I'll have another version out for download in a few days. After that, what else are people interested in?


Mike

very slick! i'll download it when you post it. there's not much more you really need in a basic client. what i have leetIRC do when you scroll up in the buffer is still keep processing incoming packets and append new lines to the buffer even if you're scrolled up. if you have pc speaker beeps enabled in the options menu, it will let you know there's new data to look at but doesn't interrupt your reading by automatically going to the end.

you could add a "repeater" feature, designed to annoy the hell out of people in a channel. just have it toss back out every incoming line from a channel right back out to it. i made a little bot that did that once, and enabled it in a few channels on dalnet for a while. some people got furious, and others got a kick out of it.:p

i even had an option that would translate each line into pig latin before sending it back.

mbbrutman
June 16th, 2008, 05:17 AM
I didn't put lines into a buffer as they come it. That's just more memory being consumed. Having the TCP stack do it seems to be correct to me.

Has anybody else besides Mike C and Trixter tried it? It's really very fast on old hardware (XT class), and I'd be happy to help people set it up.


Mike

dongfeng
June 16th, 2008, 05:23 AM
I'll see if I can try it on my XT tonight :)

Trixter
June 16th, 2008, 09:57 AM
I didn't put lines into a buffer as they come it. That's just more memory being consumed. Having the TCP stack do it seems to be correct to me.

Has anybody else besides Mike C and Trixter tried it? It's really very fast on old hardware (XT class), and I'd be happy to help people set it up.


Sorry, haven't had time to do any oldskooling for the past two weekends; I'll try to remember when I finish up some stuff. My plate is somewhat full these days. (http://trixter.wordpress.com/2008/06/11/crushed-under-the-weight-of-my-own-fun/)

mbbrutman
June 16th, 2008, 07:09 PM
The new version is posted .. look for irc-2008-0616.zip at http://brutman.com/Dos_Networking/software.html .

Major changes:


Backscroll buffer now available
Beeper toggle is done by Alt-B instead of the '/beeper' command
Statistics command added (Alt-S)


With a 200 line backscroll buffer it requires about 160KB of memory. Without the backscroll buffer it is around 135KB. That includes the entire TCP/IP stack with the ability to resolve DNS names - you don't have to add the overhead of a TSR based TCP/IP. It also includes some pretty generous buffering.

Mike Chambers
June 16th, 2008, 08:23 PM
very nice! i'm liking it. it's all most people would need in a small DOS client. the buffer seems to work very well.

mbbrutman
June 17th, 2008, 06:57 AM
Grr ... a few bug fixes are available. (The backscroll buffer support was dodgy with large buffers. I got bit by 16 bit vs 32 bit arithmetic.)

While I'm here ..

Memory usage without a backscroll buffer is around 130K:

76KB for the executable
30KB for incoming buffer space for Ethernet packets (probably overkill)
10KB for the TCP/IP socket buffer (probably overkill)
8KB for outgoing buffer space for Ethernet packets (probably overkill)
2KB for an internal buffer used to parse messages
Stack space, global variables, etc.


With a 200 line backscroll buffer it is around 165KB. And with a 1000 line backscroll buffer it is around 293KB.

Add some room for DOS and the packet driver, and you should be able to run on a 256K machine even with the default 200 line backscroll buffer.

Mike Chambers
June 17th, 2008, 07:50 AM
the leetIRC backscroll buffer is 1000 lines. 160 bytes per line 160*1000=160000 bytes, due to storing the attribute byte interleaved with the text just like in the video card's memory.

my exec is over 100 KB, lol. i'm not sure exactly how much TCPDRV eats up, but in addition to that TSR my data in and data out buffers each use up 2048 bytes.

mbbrutman
June 17th, 2008, 11:51 AM
Well, our goals are different. I want my IRC client to be:


Small enough to fit in a 256K machine
Fast enough to be tolerable on an XT or PCjr class machine
Enough features to be usable, but not much more. I'm not trying to clone mIRC or XChat.


I think that I have a very high performance TCP/IP stack - my netcat program proves that already. An IRC app is probably more useful to a wider variety of people, and will help me test the code more. (Jim already found a big oopps for me - it was just a matter of being in a different environment.)

I probably can make due with a lot less buffer space - the TCP stack is doing the receive window correctly, so it can actually throttle the flow of data by itself. I'm being paranoid by giving the packet driver 20 buffers (each 1500 bytes) to work with and the TCP stack 10KB to work with.

The user interface has been interesting to work on, but somewhat of a pain in the rear. You never realize how inefficient a user interface is until you code one. There is lots of memory movement and lots of calls occurring to set things like color and cursor position. Server side code is generally better to work with because the user interface can be minimal.

Ultimately, I still want a telnet BBS running natively on a PCjr. :-)

Mike Chambers
June 17th, 2008, 02:36 PM
Well, our goals are different. I want my IRC client to be:


Small enough to fit in a 256K machine
Fast enough to be tolerable on an XT or PCjr class machine
Enough features to be usable, but not much more. I'm not trying to clone mIRC or XChat.


I think that I have a very high performance TCP/IP stack - my netcat program proves that already. An IRC app is probably more useful to a wider variety of people, and will help me test the code more. (Jim already found a big oopps for me - it was just a matter of being in a different environment.)

I probably can make due with a lot less buffer space - the TCP stack is doing the receive window correctly, so it can actually throttle the flow of data by itself. I'm being paranoid by giving the packet driver 20 buffers (each 1500 bytes) to work with and the TCP stack 10KB to work with.

The user interface has been interesting to work on, but somewhat of a pain in the rear. You never realize how inefficient a user interface is until you code one. There is lots of memory movement and lots of calls occurring to set things like color and cursor position. Server side code is generally better to work with because the user interface can be minimal.

Ultimately, I still want a telnet BBS running natively on a PCjr. :-)

that's one advantage of your TCP stack, having so many buffers. with my prog, if i don't call the TCPDRV interrupts often enough to retrieve incoming data it's buffers will fill up and cause problems.

i absolutely agree with the telnet BBS too, that's something i've always wanted on my XT. I've tried synchronet on it, but rob swindell has not worked on the DOS version in many many years. it does not have native telnet support.

his source code is available, mike. since you're a C guy, you should look into modifying it to redirect the output through TCP rather than a com port. i suggest this, because other than not having TCP support synchronet is an AWESOME piece of BBS software. i think i might start working on my own BBS when i get this IRCd finished.

btw, after i modified leetIRC to use print and display no color on mono cards it is very tolerable on 8088-based systems. if you have a VGA card in it, you can still do LEETIRC.EXE /MONO to get the big speed increase.

mbbrutman
June 17th, 2008, 02:51 PM
TCPDRV is a TSR, so it is kind of limited as to what it can do with memory allocation. I think that everything has to be statically allocated, which limits how much memory it has access too. I don't have that problem - I can use the entire machine for incoming packets if I want to.

On the other hand, the TSR approach is more forgiving about bad user programs. I assume that it hooked the timer tick interrupt, so it is getting a chance to run about 20 times a second. The user program needs to pull data from the TCP stack periodically, but it does not have to do anything special to keep the data moving. In my approach (also used by NCSA Telnet and WATTCP) the user program has to keep making calls to the TCP stack to keep the lower levels of the stack moving - there is no periodic interrupt.

Sorry - I'm not picking up any more projects. I've got a few too many already. Redirecting COM port traffic to a TCP socket is not trivial .. COM port traffic is done a byte at a time, while TCP traffic is done in packets. If you do it naively you will wind up sending one byte per packet, which is a nightmare ..

You've got my Borland C++ 3.0 compiler - you give it a shot.

My code runs fast, color or not. :-) All I need is a name for it ...

Mike Chambers
June 17th, 2008, 03:28 PM
TCPDRV is a TSR, so it is kind of limited as to what it can do with memory allocation. I think that everything has to be statically allocated, which limits how much memory it has access too. I don't have that problem - I can use the entire machine for incoming packets if I want to.

On the other hand, the TSR approach is more forgiving about bad user programs. I assume that it hooked the timer tick interrupt, so it is getting a chance to run about 20 times a second. The user program needs to pull data from the TCP stack periodically, but it does not have to do anything special to keep the data moving. In my approach (also used by NCSA Telnet and WATTCP) the user program has to keep making calls to the TCP stack to keep the lower levels of the stack moving - there is no periodic interrupt.

Sorry - I'm not picking up any more projects. I've got a few too many already. Redirecting COM port traffic to a TCP socket is not trivial .. COM port traffic is done a byte at a time, while TCP traffic is done in packets. If you do it naively you will wind up sending one byte per packet, which is a nightmare ..

You've got my Borland C++ 3.0 compiler - you give it a shot.

My code runs fast, color or not. :-) All I need is a name for it ...

TCPDRV is kind of weird, it doesn't attach itself to the timer interrupt. here is a copy/paste from the official spec:


driver_doio

Perform driver processing

Will call event handlers as required Must be called regularly to process packets.

call
ah = 02H
return
ax = no. of free pkts on IP input queue
cx = no. of free pkts on IP output queue
dl = error code

that's the interrupt function i have to call to make it process. i read elsewhere on the page that it can be attached to the timer interrupt if i want it to be automated.

i just put a call to it in my status monitoring DO LOOPs so it keeps getting called once every time the loop is run.

Druid6900
June 17th, 2008, 07:37 PM
My code runs fast, color or not. :-) All I need is a name for it ...

BrutPhorce?

Mike Chambers
June 17th, 2008, 07:42 PM
BrutPhorce?

hahaha

i love it! mike b, name it BrutPhorce. that's better than leetIRC. that kind of sounds lame. i wouldn't mind changing it's name, but i can't think of anything better.

mbbrutman
June 17th, 2008, 08:18 PM
DOS - has to be 8 chars. ;-0

And 'Bruteforce' is taken:


login as: brutman
brutman@bruteforce.rchland.ibm.com's password:
Last login: Tue Jun 3 08:45:26 2008 from ibm-435f5d72d9b.rchland.ibm.com
[brutman@bruteforce ~]$ uptime
22:53:19 up 50 days, 13:51, 5 users, load average: 0.00, 0.00, 0.00
[brutman@bruteforce ~]$


That's been the name of my workstation since 1992. The first Bruteforce was an RS/6000 model 340. There were some upgrades. Eventually Bruteforce turned into a Linux x86 machine.

Good call though ...

Mike Chambers
June 17th, 2008, 09:51 PM
DOS - has to be 8 chars. ;-0

And 'Bruteforce' is taken:


login as: brutman
brutman@bruteforce.rchland.ibm.com's password:
Last login: Tue Jun 3 08:45:26 2008 from ibm-435f5d72d9b.rchland.ibm.com
[brutman@bruteforce ~]$ uptime
22:53:19 up 50 days, 13:51, 5 users, load average: 0.00, 0.00, 0.00
[brutman@bruteforce ~]$


That's been the name of my workstation since 1992. The first Bruteforce was an RS/6000 model 340. There were some upgrades. Eventually Bruteforce turned into a Linux x86 machine.

Good call though ...

no check this out

BRUTFORC.Exe

you gotta be creative with these 8 char limits, it's like coming up with a vanity plate for your car.

carlsson
June 17th, 2008, 10:48 PM
Pardon me, but shouldn't it be BRUTFIRC.EXE as Mike is developing an IRC client? Or simply BRUTIRC, give or take silly capsing.

Mike Chambers
June 20th, 2008, 09:07 AM
Pardon me, but shouldn't it be BRUTFIRC.EXE as Mike is developing an IRC client? Or simply BRUTIRC, give or take silly capsing.

mike b's is more or less just to exercise his TCP stack code... mine is a bad attempt at putting all or most of mIRC's functionality into a DOS proggie. :p

yeah, "most of" works better... i am NOT about to try and re-create mIRC's scripting functionality!!

Druid6900
June 20th, 2008, 03:21 PM
ChamIRC?

"Remember to Cha-Cha-ChamIRC" :)