TCP/IP Testing help, Round 2 - Done!

This round of testing is over. Here are the highlights: - No heap corruption since I fixed the buffer overflow bug this morning. (Doh!) - I have a lot of a lot of open connections in ESTABLISHED state which I suspect are no longer valid, but because there is no data transfer there is no error. I already knew I'd have to implement a session timeout or keep-alives, and this confirms it. - I have one connection in FIN_WAIT_2. I suspect that will never close on it's own because the host has long since forgotten about it, so I'll need to implement a cleanup timer for those. (I read that Berkeley derived stacks do this, even though it is a violation of the spec.) - I suspect I need to work on my RST segment processing - I think I'm being too strict about what I consider to be an allowable RST. It's all in the RFCs, I just must not be grokking. I'm not going to be testing anything again anytime soon .. it's back to real work, and I have a lot to do before I can subject anybody to my code again. Besides the issues above I need to work on the following: - Besides tracking window sizes, actually honor them. (My code is ill behaved, and can send more than the window advertises.) - Telnet options negotiation - Some sort of 'select' call so that the app doesn't have to keep polling each socket directly. This is DOS so underneath the covers it will poll anyway, but having the app do it makes the code nearly unmanageable. - Go through the logs (both on the server machine and the tcpdump logs on the Linux firewall) and see what else I goofed up. Once again, thanks to those of you who helped me test. I've never undertaken something this large at home - this has been a year in the making. TCP/IP on an 8088 class machine isn't particularly new and exciting, but having my own implementation allows me to determine the balance of features and performance, and to fix the dang bugs that will pop up. :-) This code (without disk access) can transfer an receive on a socket at over 50KB/sec on a PCjr with a NEC V20. That ain't shabby .. :-) Mike