• Please review our updated Terms and Rules here

extended test of my DOS IRC server! :)

M

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621
i thought i'd make a new one to get more hits and people logging in. feel free to close the other thread!

i am still lacking PING (that's a biggie, i know) functionality, along with recognizing a few commands:

USER, USERHOST, WHOIS, and a couple other little ones. right now it just assumes everybody's user line is "nobody".

after i implement all that (After a successful test session here, hopefully for a few days) i am going to hardcode services (nickserv/chanserv/etc)

i believe i have completely solved the occasional lock up issue i was having. stupid oversight where i dimensioned the input buffer string for TCP connections to be 2048 bytes long, yet when i called TCPDRV hook to dump the data into them, i told it that up to 4096 bytes was okay! D'OH!!!!

i've been up for days on my LAN with me logging and and out from different machines and many different clients.

feel free to check it out.. /LIST works too and there are channel topics now. i'm basically just hanging out in #test - don't feel disheartened if i'm not there actively talking :p just hang out and idle if you don't mind. people will be logging in and out i hope.

server: 66.190.143.6
port: 6667

thank you, and wish me good luck as far as it not crapping out and locking up goes!! that would be nice if it doesn't crash...

it IS running on an 8088 at 4.77 mHz, and i think the performance for a multi-threaded chat server is actually VERY impressive considering the processor and the language it's written in (uyyyyy! QB45 for the win)
 
update for those who care.

ping function is done, and works well. now it discards dead connections that don't respond with a pong. the ping interval and ping timeout are both customizable via the dosircd.ini file.

just for the sexiness factor, the server will show the lag time in milliseconds from the last ping on the screen next to the handle/IP/nick of each client.

it's only accurate to 1/18.2 seconds, or approximately 55 ms. it's limited to the system timer's resolution. i would imagine most people would be less or near than 55 ms lag in today's broadband world, but it shows it anyway. :)

what i'm working on now is channel/user modes and the enforcement of them. after that, services need to be written and then it will be time to put it online for a very long test run to find bugs if they exist.

i think i might put a small forum on my website so that people who are interested in my programs can just go there for updates and discussion, rather than bugging you guys every time i click "save".... that'd also be a nice way to help people who have problems or questions.
 
you've been a pretty faithful tester every time i make a post about this, JoJo. thanks! :)

JoJo and anybody else who wants to help a starving open-source programmer out, please fire up your client of choice and IRC to my server:

address: 66.190.143.6 or by hostname retrobox.scieron.com
port: 6667

it is pretty much 100% compliant with the old 1993 specs in RFC 1459. one of the things that is not compliant about it is that it does not in any way support multiple servers. i don't want to spend 2 years writing this thing, and i think for a simple DOS IRCd that would be overkill! i also still need to implement modes for channels and users.

it supports WHOIS, USER, and all the other usual commands. i even wrote a simple host mask feature (toggled on/off through DOSIRCD.INI file) so that only you will see your own real IP address. everybody else will see a masked version.

it also does ping connections periodically to check for dead ones, that was a major problem before. the ping interval and timeout can be changed in the INI file.

it's running on the 286 right now, and i want to see if it can do 2 or 3 days without any crashes or issues. thanks to those who help! if it passes the test here, i go on to write service bots for it. i also will probably add some of the more useful IRC extensions from later RFCs, and then it will be ready for public consumption. (i hope)

source code is up to 60 KB now, and compiled in quickbasic 4.5 it makes a 70 KB EXE file.
 
Last edited:
d'oh! looks like it locked up at some point. i need to add a file logger for debugging, otherwise i'll be sitting here with no idea why it keeps crashing. i'll have it back up shortly.

i see you guys had problems getting the user list in the channel. i know what the prob is, and i'll fix that too.
 
from IRC log said:
[20:28] * mike_c changes topic to 'i just found a major problem with the code and fixed it. when i have outgoing data, it splits it up into separate blocks of 1024 bytes to send separately if the whole payload is larger than 1024... but i just realized i was having it send 1024 bytes from the string pointer even if the string is smaller than that. may have been causing issues. we shall see i guess.'
[20:41] * mbbrutman has joined #test
[20:42] <mbbrutman> Funny, IRC packets are supposed to be 512 bytes, right?
[21:53] <mbbrutman> Ping
[22:31] <mbbrutman> Anybody there?
[22:39] * mbbrutman has quit IRC
Click to expand...

yes, mike. sorry i had to run some errands. i stuck around for a few minutes but i didn't see you log in yet.

yes IRC "packets" (as in each CR-LF terminated line) are supposed to be a max of 512 bytes including leading data and CR-LF. mine does limit it to that, but as the spec suggests if i have more than one line responses going out, (for example from a WHOIS query you'll get several lines of data back) it should bunch them together and transmit them together from an output queue rather than each line being in it's own TCP packet when possible. and that is VERY good advice if your target platform is 8088s and 286s :)

from looking at my code, it looks like vlad and jojo's inability to see users in a channel is from a problem in the handling of the NAMES command. this is exactly why long test sessions are good!
 
Last edited:
mbbrutman said:
It's called buffering. I think I know a bit about high performance comm code. ;-0
Click to expand...

yeah, that's what it's doing basically.

oh speaking of buffers, i think i know what is causing the occasional lock ups now. i ran the same compiled exe that was locking up on the 286 and tried it on a 1.8 gHz pentium 4 with a DOS installation last night. i had multiple computers in my house connect and disconnect randomly for a whle, as well as feed random garbage strings into a channel. it didn't lock up at all. there were around 10 simulatenous connections at any given time, i had no issues.

i think the culprit is just the fact that the 8088 and 286 not being fast enough to deal with more than a couple users at a time before the TCPDRV buffer fills up. i talked to peter tattam about this too, he agrees with me that it's likely the problem. i had it going for 2 days on the 8088, and it never locked up but there were only 2 connections.

so what i will do is just make sure it does the tcpDoIO way more often than it does now, and maybe make TCPDRV's buffers a little larger which can be done with arguments at the CLI. maybe i should just hook the IO handling call to the timer interrupt.
 
So what happens if the TCPDRV buffer fills up? It should just send a 'zero window' msg to the other side, so that the other side knows to stop sending data. When the buffers have space again the 'windows open' so that more data can be sent from the other side.

Is TCPDRV not doing the zero window notification? Even if it is dropping packets, it should still be causing retransmitts to occur.
 
i hadn't done anything to the server for a few days, but i think i've got the bugs worked out (i hope) and it'll be up again soon for another test.

i fixed the problem that some clients had where you couldn't see who was in a channel after joining it. if this test session is bug-free, then i am going to code nickserv/chanserv/operserv/memoserv and then i can call it "complete" i think. it will then be available for download, including the source.

EDIT: i went ahead and added some forums to my website at www.rubbermallet.org - i am going to stop bugging you all with the tiniest little updates on this program, and i'll mostly be talking about it over there. i will still post here when it's finished or if i need to beg you guys to give the server a good workout! :)
 
Last edited:
check out this handy little feature i just added. you don't have to actually physically go to the computer running the server to see what is going on. you can now just telnet into it you, and you can see exactly what is on the remote screen as if you were in front of it's monitor.

dosircdtelnet.png


^ here, the IRCD is running on a 286 box on my LAN and i am connected to it from an XP box while also keeping a telnet connection open to see everything on the 286's screen. it's basically a text-mode implementation of VNC.

it's pretty quick, too. every time the telnet handler subroutine runs, it checks each of the 25 lines on the screen for a change and if one is detected it uses ANSI escape codes to go directly to that line and refresh it.

now i can be even lazier!!
 
Last edited:
wow, this is getting pretty crazy. my source code is up to 103 KB now! last night i spent a lot of time on this, and have the beginnings of services written. nickserv now make you identify if your nick is registered, and changes your nick to a no_name nick if you don't within 1 minute. i don't think i've written a program quite this large before. there are so many details you have to take care of in an IRCD!

i still need to write the register, drop, and ghost features for nickserv. right now you have to edit the nickserv.ini file by hand if you want a regged nick. that part will be pretty easy.

also, i've gotten all the channel ops stuff finished. it really is a P.I.T.A. to code all this stuff. it wasn't all that complicated until i got to the op handling and services. still need to write KICK and BAN code, and some other stuff as well.

also need to make chanserv and operserv work. my brain is hurting.

good news; to the best of my knowledge, all lock-up issues have now been taken are of as of last night. there were a few things that could cause the lock-ups, i had fixed a few before. apparently if a client got disconnected while it was in a do loop waiting for data or something like it, since i didn't have tcp status checking routines in some of the loops they would lock up if the client's connection died and just kinda be stuck there forever.
 
Last edited:
quick note to anybody interested in the program, i believe it is very very stable at this point. i haven't seen any lock ups since the last debugging marathon.

right now, it is online running on a lowly 8088. go ahead and stop by if you want to.

server: retrobox.scieron.com
port: 6667

i'm going to leave it up for the rest of the day, and probably until tomorrow morning. one thing i would love to get tested is the nickserv bot i hard-coded into the server.

in my own testing, everything seems to work fine with it but i'd love it you guys gave NS a test. the commands it supports are: register, drop, identify, and ghost.

/msg nickserv help
^^ in case you need it, it has built in help

oh and just to let you know, it stores the passwords in plain text when you register at the moment. i'm not going to h4x you guys or anything, but i wanted you to know about that anyway. you'll probably want to use a password that you don't use anywhere else. i'll be using hashes in the near future instead. MD5, SHA-1.

does anybody else know of any cryptographic hash algorithms that are simple enough so that i don't spend 12 hours on that part alone? :)

anyway, MD5 is hungry and will eat all the CPU cycles it can... 8088 + MD5 = bad idea.
 
Last edited:
hmmm, i am looking at the IRC specs for linking servers to form networks... it's actually not that complicated. i wonder if it's worth taking the time to add it to my server.
 
Ok, I just logged on to see three users but no one in #test? I'm not so familiar with IRC so I don't know if people would hang out elsewhere.

By the way, I'm using the ERC client in Emacs. It seems to send are-you-there requests once in a while, which your server doesn't appear to understand?
 
carlsson said:
Ok, I just logged on to see three users but no one in #test? I'm not so familiar with IRC so I don't know if people would hang out elsewhere.

By the way, I'm using the ERC client in Emacs. It seems to send are-you-there requests once in a while, which your server doesn't appear to understand?
Click to expand...

ah yes, there some commands not implemented yet. i'm working on it, and no we aren't in #test but we should be. oops.

you can just type /list though and you'll get a list of every channel on the server.
 
yes, it was fun! i would be there chatting right now, but then i'll get distracted and not be able to focus on writing new code and repairing old code. ;)

man, you guys are gonna be impressed when i release this software i think. i even have a small built-in HTTP server, designed to allow (password protected) web administration and real-time monitoring of the server.

it's just protected with the standard "basic" HTTP auth method. it can also be access-restriced to a customizable IP address mask. for example, on my network i'd put this line in the DOSIRCD.INI file:

webaccess=192.168.0.*

EDIT: here's a screen shot of IE displaying the dynamically generated main status page. this is very preliminary, and i just started writing this web admin code a few hours ago. there will be a lot more in there when it's done.

webadmin.png


:mrgreen:

for the web interface, i'm planning stuff like viewing the whole online client user list with detailed info if you click on one of them. ability to kick/ban from server from the web, etc, etc.. you will be able to directly modify the *.INI configuration files right from the browser, save changes, and have it reload the new configs all without shutting down and kicking everybody off of the server. yes, i am the undisputed master of QuickBASIC thank you for asking. i've been working verrrry hard on this IRCD, so you'll have to excuse my short gloating moment there. it's just great seeing it all start to come together and be stable.

i think it'll be ready to download for the public before august.

it'll be nifty. i'm doing it using HTTP 1.1 keep-alive, so updates are always live and real-time.
 
Last edited:
You must log in or register to reply here.
Back
Top