fixed my TCP routines multi-thread server issue!

[Mike Chambers]

mike b, i know i was telling you about this one. i had apparently made an error in my tcpClose sub, where i specified a zero timeout value for the call. i was looking at the TCPDRV spec docs earlier today, and noticed it said that the handle will not close properly and may have unexpected results if i call it with a timeout of zero. what happens, is that it doesn't recycle the handle properly. soooo, once all the possible handles have been connected and then not recycled after disconnection... the server just kinda sits there being useless until i reloaded tcpdrv.

i went ahead and patched that up, and wrote a little tiny prog that has 8 ports open at once, and shows me the status of each handle in real-time as i used my laptop to connected/disconnected to them in random orders via telnet.

i had the prog forward anything typed from one telnet session to every other one, and sure enough... everything works!!! i'm happy.

this means i can finally re-write my HTTP server from scratch and actually let it handle more than one connection at a time. i'd love to make it an all-in-one HTTP/FTP server actually.

first, however... i am just going to sit down here on the XT for a few hours and code a very very basic and no-frills IRC server. when it's ready, i could post the address to it here. i'd appreciate it if you guys would all help me out bug-testing this. i'm not expecting any problems, but better safe than sorry eh?

i'd like to keep it up and running for at least 24 hours, hopefully with plenty of people logging in.

 

[Trixter]

Can do, but I just found one project you can scratch off of your list:

http://josh.com/tiny/

Amazing

 

[Mike Chambers]

haha i stumbled across that yesterday actually. i downloaded it, but haven't tried it yet.

 

[mbbrutman]

Good job debugging. It is always important to not violate a spec .. The spec contains the bugs they know about.

The key to keeping something running for a long time is to ensure that you have not memory leaks and no buffer overflows.

In Dec 2006 I did my first major test of my TCP/IP stack - 8 open 'lines' for telnet clients to connect to and interactive with. It had a simple menu system and a few functions, like 'show me the BIOS date of this machine' or 'dump out the TCP/IP stats'. It ran for a while, but eventually flaked out - I can't remember the specifics of the bug, but it came to me while walking the dog and it was pointer related. After that, it ran for three days straight with no resource leakage.

I did a similar test in Dec 2007, but this time I added a chat facility. It went for 5 days. I thought I had things under control.

This week Trixter broke my code .. it lasted for a few minutes. He had those funny packets on the network, which I didn't anticipate. That caused a resource leak, and then shutdown as the number of incoming packets dwindled to zero.

As bad as QB is for speed, it does protect you from pointers and memory allocation issues. I'm a top notch C/C++ programmer, and I've done low level operating sytem work for years, and even I get caught by a memory allocation or pointer bug once in a while. You basically have to trace the usage of every memory allocation to make sure it gets deallocated and recycled in a known and repeatable manner, and the simpler your code is the better.

Good luck on the test ..