Intrafoundation Software
Making Atomic Warfare Fun Again
News & Forums Active Projects Queued Projects | War & Politics God Cryptography Operating Systems Game Development | Writings Poetry Film Making Wisdom | ColdFusion ASP COM Objects Javascript Web Design Java | Photography Raytracing DOS Software

Note: This page is under development. This software is not available to the public.

| # IntraTCPIP For use on websites with ColdFusion, ASP, PHP4, Visual Basic or C++ ## v3.0 (NOTE: A SSL + S/MIME version 3.x of this object is on the backshelf.) `Send related correspondence to: products@intrafoundation.com` (RELATED PRODUCTS: NetworkTopology, UDPClient, TCPClient, IntraTCPIP ie TCPClient 3 w/ SSL + S/MIME) The COM object Intrafoundation.TCPClient allows you to talk to any Internet server using TCP/IP such as: `HTTP, NNTP, POP3, SMTP, IMAP, IRC, FTP, WHOIS, ECHO, RLOGIN, FINGER`, etc. You could for instance ask an internic WHOIS server to return information on a domain name. Or you could do a FINGER on JOHNC at IDSOFTWARE.COM to read John Carmack's .plan file. Or query a POP3 email server, or an NNTP news server, or an FTP server, or just about anything else. Simple, but useful. More specifically it provides for asynchronous communications to any TCP/IP based server (which is just about everything higher-level on the Internet). You can send text messages to or receive messages from any of these servers. You can send or receive binary data back and forth from them as well. This COM object provides only the elemental, base functionality you need to talk to these servers. As for what you're supposed to say to them and what do the messages they send back mean, well... Try reading the official RFC text documents to learn their languages. But, as an example, a good way to start out with the SMTP mail server is to simply hold out a hand and say: `HELO` What you do afterward is up to you.... `--min` ### COPYRIGHT / TERMS OF USE This software is Copyright (c) 2000, 2001, 2003 by Lewis A. Sellers. It is not public domain, nor is it GPL'ed, but it is very close. As long as you do not modify any files in the archive, nor add to them, nor delete any of them, and do not charge for access to said archive you may redistribute the archive as you like. You may use this software as-is with any software you wish, so long as said archive is included unmodified with proper credits and link to it's homesite is included also (http://www.intrafoundation.com/IntraTCPIP.asp). You may modify and use the source code as you like -- with the understanding that if you do, you still have to include the original, unaltered archive as well as the aforementioned credits and link. You may use this software in commerical applications, whether closed-source or open-source so long as the aforementioned unaltered archive is included with the application and the aforementioned creditation and hyperlink are included. If this software is used in a released project or included in a publication you are to make reasonable efforts to contact the author and notify them as to such. The author of this software has a primary email address of: products@intrafoundation.com. You use this software at your own risk. ### V e r s i o n H i s t o r y 3.0 - October 27th, 30th, November 9th, 16th, 17th 2001. Added a lot of SSL support. Slight redesign of COM interface for SSL. Changed from "yellow constuction paper" look to "nuclear fire-storm red". New graphics. All of the SSL support should be treated as "alpha/beta" code for a version or two. That is, potentionally unstable. Additionally, until I have a chance to review the current munitions export regulations (in light of the September 11th terrorist attacks) all cryptographic algs are "international" grade. In other words, close to worthless if an organized attack was made against your communications stream. It's not exactly good COM programming style to add new functions to a COM without providing a legacy interface to the original style... however since a) this isn't an anal-retentive commerical product and b) all the changes happened to functions that were marked as "reserved for future expansion"... just deal with it. The COM interface is now Intrafoundation.TCPClient.3. Added extra MIME and BASE64 support for S/MIME and PEM. Specifically added a smart decoder which can automagically handle all NNTP, POP3, IMAP4 and HTTP style MIME or UUENCODED data. It can encoded or decode these messages in command. See getMIME and putMIME. Added DNS lookup results property... Added section describing how to use PROXIES with HTTP, etc. (Everything you need to know about anything is in the RFC's, but it sometimes escapes me that most people have a bit of difficult understanding their techno-speak.) The 2.x version of the tag was downloaded approximately ~5,000 times over the last year that I know of, FYI. For the most part I have no idea what people are doing it with (though I have encountered at least one person re-branding it and trying to sell it for a couple hundred US$ to ASP folks ;-). I actually don't care if people do this, except that it bugs me they use some documentation verbatim and they also conveniently forget to mention where they "borrowed" the code from.) On that note, perhaps I should mention that this software was writtenly entirely by myself with partial exceptions for the cryptographic parts. For the MD5, SH, SHA, RC2, RC5, DES and 3DES algorithms I had to heavily rely on the Applied Cryptography book and various published RFC's and other technical documents and (PERL-ish) source codes. That said, I built the code with my own two hands with no other outside help. (Coding sessions brought to you by Dave Navarro: Trust No One and Staind: Break the Cycle and Filter: Short Bus.) 2.15 - Octember, er, October 27th 2001. Added SSL support.... 2.14 - September 13rd 2001. Added PING. 2.13 - September 3rd 2001. Revised copyright text to clarify issues people had been asking me about. While building UDPClient with TCPClient's project code over the weekend noticed the kbps speed functions were saying a kilo-byte was a 1,000 bytes, not 1,024 bytes as is proper. Oops. Fixed here in tcpclient as well. 2.12 - Feb 8th 2001. Doc, example and source clean-up. 2.11 - Feb 3rd 2001. 2.11 consists mainly of bug fixes and performance tweaks. In some situations 2.11 is actually 30 times faster than 2.10. (Seriously.) Changed internal buffer size to 32768 bytes which gives about the best LAN performance on w2k according to tests Recoded the "connected" functions to be faster Added 20 millisecond delay to match the Nagle alg for buffer-full sends Fixed RecvRN bug that could cause a crash when remote server drops connection Added experimental kilobyte-per-sec stats for send/recv 2.10 - Feb 2nd 2001. (Brought to you by Olivia Tremor Control.) A few minor tweaks, including memory/speed optimizations. In short, when doing large data transfers in the 1mb to 30mb range the tag was scaling very badly. It threatened to crash the machine on more than one ocassion. This has been addressed. Oh... So, it seems the uu encode/decode functions have never worked. Ever. :) I originally coded them completely from memory and never tested them. (Never needed to use them until this week.) Of course it turns out I forgot to code for the line length markers. Anyway... sorry about that. Recoded base64/uu routines. Fixed. Added blocksize for Recv. Added hascutoff indicator property. Changed default tcp buffer size from 512 bytes to 8192 bytes. Added several additional status properties relating to network buffer sizes. Changed error log to emits CRLF's instead of <BR> for line ends. Some misbehaving servers applications (such as Post.Office 3.5.3) have a habit of emitting spurious NULL's after a CRLF on the mime boundries resulting in Recv/RecvRN thinking there is no further text following. Addressed this. The UU and base64 code wasn't working properly. Fixed. Send failed with a 30mb file. Reworked to send large blocks of data. I believe it's safe to say we're probably in a feature-lock now. There are a few undocumented or reserved functions that have yet to be implimented (mainly SSL) but those aside the emphasis from now on is debugging and optimization. The COM interface is locked at Intrafoundation.TCPClient.1. There have been enough significant code changes to 2.10 that I'd almost thought of calling it a beta for a while. Bit of caution here. 2.9 - Jan 24th, 27th 2001. After a few long emails with Bryan Owen, the tcp class underwent an intense low-level debugging session to root out the glitches in a new caching implimentation of RecvRN. While I was at it... there were several changes made in the fundamental tcp c++ class that's the heart of this COM object. (For those who haven't looked, this is a C++ project with two classes: The COM object tcpclientcom itself and a class called "tcp". The tcp class is used in several other projects, most commercial or for-hire. This COM is used as a sort of an open-source test-bed for that critical class.) Redid the documentation to make things clearer. Rewrote RecvRN to give it it's own tcp-level class so as to avoid forcing tcp/ip timeouts (ie, cache misses). Redid the pop3, smtp and ftp localhost tests to use RecvRN. Much smoother response time. The tcp class function send wasn't properly reporting the bytes sent. Several misc undocumented polishings to tcp class. Fixed sticky error log. Cleared on any open now. Fixed misreporting class file names. Added a simple, crude little news browser. I keep tripping over the folks at fuseware.com. I'm sure they love me. :) 2.8 - Jan 21st 2001. Misc doc and script cleanup. Changed NNTP example to forums.macromedia.com (our new overlords). 2.7 - Jan 3rd 2001. Misc. Polishing. Been meaning to replace all the place holding graphics with simple (2001: Space Odyssey-ish) white plastic theme. Small spherical indentation grids across top. Washed out by intense white light. Haven't had the time. Oh well. HACKER WARNING: The DECODEASFILE can be exploited. Then again, this entire tag can be one big hacking exploit when in the right hands. But, just fyi in case you were thinking otherwise. You really shouldn't install this on a shared host. If you have ideas on how to modify it to have a "safe" mode (or, better yet, a conditionally compiled safe release version) feel free to express yourself. 2.6 - 12/24/2000. Fixed cutoff. It was only checking when the remote server paused. Now checks after every packet. Added RecvRN. 2.5 - 12/21/2000. 'ello. It was intending to GPL this software, but as I was preparing a formal GPL notice it occurs to me that since it prohibts inclusion in proprietary software (which parts have already been used in and will be so again) it can not be so. And thus I mispoke if I said it was to be so. Sorry. As to what "license" this software has... Not sure if any fit it. For now I really don't care what you do with it as long as you give proper credit to me (name, url, etc). I would prefer you keep it open source, but if you make significant changes you don't want to share, I understand. The only thing that would really annoy me is if you (like one unnamed creature with 1.x) change the headers and claim you wrote it. :-) If you develop a nice script (in your native CF or ASP VBSCRIPT, etc) that's a front-end to a protocol (POP3, FINGER, etc), you're perfectly free to distribute the script with the COM object as long as you also include the full archive (the .zip), etc. I also encourage you to send useful completed scripts to me for future inclusion. You may feel free to place this in any free online component sites. Saves me the hassle of having to do it myself. Oh, and I changed the ClassID from TCP.Client to Intrafoundation.TCPClient. Meant to do that earlier, before beta. Slipped my mine. Also fixed it so you can can use the version independant clsid "Intrafoundation.TCPClient" instead of "Intrafoundation.TCPClient.1". Removed references to SENDSTRUCT and RECVSTRUCT. Probably be a few other "settling" issues for a few more revisions. This is brand new code after all. PAX. 2.4 - 12/21/2000. Non-beta. Clean-up. 2.3beta - 12/20/2000. First wide-beta. Final documentation (and replacements for the little placeholding squiggles) remain. Send in your functioning scripts for inclusion in future revisions. BTW, as with 1.x I do essentially consider this software GPL'd. As far as I'm concerned you can pretty much do what you want with it, as long as you don't claim you wrote it yourself. :-) 2.2alpha - 12/19/2000. First documented public release. Finished CSV functions. Only encoding functions, datalimit implementation and final documentation remains. Added to interface possible future additions that would support bit-level structs and SSL (Secure Socket Layer), aka HTTPS. 2.1alpha - 12/18/2000. First (undocumented) public release. 2.0alpha - 12/7/2000, SECOND EDITION. Brand new ATL COM, written completely in C++. This Second Edition of TCPClient competely replaces the old Allaire ColdFusion only version. 1.2 - Nov ? 2000. Just a repack with a different version number. Apparently 1.1 was reporting itself as a .14beta in some places, confusing some folks. 1.1 - 09/19,25/2000. Erik Willsey prompts me to make a few bug fixes. Was already moving that way anyway as I noticed it was twitchy under W2K. Added WAITFORSENDDATA. Added TIMEOUT. Fixed a few things. 1.0gamma - 09/1/2000. The ancient beast awakes. Fixed a bug.... 0.15beta - 02/17/2000. Doc tweak. 0.14beta - 02/11/2000. bug report by Jonathan. No, besides that there have been no changes since the last version. However... a bit of work in a week might require something similiar so some advances might be made. If I know where the problems are. Send in feedback. Feature requests, etc. 0.13beta - 01/07/2000. misc. examples & docs changes. contemplation of optional restriction security mode against *FILE functions and option to list ALLOWED ports (those not being listed, being those DENIED). 0.12beta - 01/04/2000. Spawned project to CFX_TCPServer and removed all SERVER/LISTEN code. Went over project. Everything seems to work. More or less. Back to beta status. If you need IDENT for IRC protocol now you'll have to also install CFX_TCPServer when I finish it. 0.12alpha - 01/04/2000. ENCODING functions finished. work now. Only LISTEN/ACCEPT code, and code/example/doc polishing remain. Some socket functions getsockname, etc are experiencing long timeouts sporatically if local DNS is overburdened. Will fix. 0.11alpha - 01/04/2000. LISTEN and ENCODING function may not currently work at all and are in an ALPHA state. The CSV functions are slugs that need to be retooled at a lower level. Everything else should be BETA and working as far as I know. This somewhat premature release is so people can do further testing on the new "engine". Have fun. Next release should be full beta. Might get a chance to do that in 3 or 4 days. 0.10alpha - 01/02/2000. not released to public. massive code rewrite. added csv SENDBINARYCSV and RECVBINARYCSV. removed temp internal 256k data limit. misc, etc. This version is possibly very unstable compared to the previous because of the massive rewrite. but very much more useful. caution. It can at least do PASV ftp to get file listings, etc now. the mime/uu/xx code hasn't really been tested. Mostly just typed it in from memory of the theory. It does compile without error though. so.... /-) I need to clean the mime/uu/xx up and then fix it so the tag can listen at a tcp port for full ftp, etc functionality. (ie, OPENSERVER and CLOSESERVER don't work yet.) I'm mulling over what to do with SENDFILE and RECVFILE to make the tag safer.... The tag goes back to alpha status for 0.10 because of an aggressive rewriting session last night that leaves much of the tag in an unstable state. However... several interesting new abilities are almost available now. Read the history. 0.9beta - 12/27/1999. misc. If I have time I'll try to debug all the BINARY stuff by next time and add in a working binary ftp example. Someone want to do a vt100 telnet client? /-) 0.8beta - 12/22/1999. minor tweaks. 0.7beta - 12/22/1999. waiting for feedback before much else gets done. yawn.... spawned off a copy of the project for CFX_UDPClient. Back to paying work. If you ever want to see a .8, then send feedback. :) This tag is still under development, but coming close to being stable. If you have feedback or want to donate* a cfm example for communicating with a certain TCP server type, then feel free. *Especially those that say "under development" such as telnet, or qotd etc. 0.6beta - 12/21/1999. first mostly stable release. essential feature-lock. donate working examples please so I can test the stability, especially those involving binary transfers. also ip's for public qotd, echo, etc sites would be nice. 0.0alpha to 0.5alpha - 12/20/1999-12/21/1999. Seriously began work on it again partially to understand TCP/UDP for linux-based network-related project. And because it was fun. 0.0 - 5/1999 made the project file. abandoned a few seconds later. |
SOFTWARE DOWNLOAD Downloaded 6 times.
Due to U.S. Export Regulations, all cryptographic software on this site is subject to the following legal notice: This site includes publicly available encryption source code which, together with object code resulting from the compiling of publicly available source code, may be exported from the United States under License Exception "TSU" pursuant to 15 C.F.R. Section 740.13(e) and Section 740.17(b)(4)(i). This legal notice applies to cryptographic software only. Please see the Bureau of Export Administration for more information about current U.S. regulations.
`This information is required for export compliance.`
Are you and the computer(s) you are operating both in the United States of America or Canada? Yes No
Are you a citizen of the United States of America, a permanent resident (with "green card") of the United States of America, or a citizen of Canada? Yes No
Are you aware of the U. S. Export Administration Regulations and similar Canadian regulations? Yes No
Country: |
Name: |
URL: |
Email: |
Comments: |
`v3.0` (`570kb`)
`Feel free to post any comments you have about this software. Who told you about it. Why you're downloading it. What you thought of it. Any bugs you might have stumbled across, etc. Any comments requiring a response might fare better in the forums however.` Name: URL: http:// Posted: 4/22/2004 2:28:35 PM Name: URL: http:// Posted: 3/23/2004 7:42:51 PM Name: Mike C. URL: http:// Posted: 11/20/2003 3:06:40 PM When is this going to be out? The ability post to an SSL site would be nice. usp@cheerful.com Name: ttboy URL: http:// Posted: 11/5/2003 3:56:24 AM look for a smtp componet Name: URL: http:// Posted: 11/5/2003 3:51:34 AM Name: fd URL: http:// Posted: 9/23/2003 10:27:07 AM dfdf Name: URL: http:// Posted: 9/23/2003 10:26:49 AM Name: URL: http:// Posted: 8/1/2003 6:24:25 PM
PUBLIC COMMENTS?
Name: |
URL: |
Comment: |
`Why? We're just darn curious that's why.` |

top