Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!rex!ames!excelan!keith From: keith@excelan.COM (Keith Brown) Newsgroups: comp.dcom.lans Subject: Re: int 14 Message-ID: <1570@excelan.COM> Date: 19 Jul 90 01:04:22 GMT References: <12920042@acf4.NYU.EDU> <12920043@acf4.NYU.EDU> Sender: news@excelan.COM Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Excelan, A Novell Co., San Jose, CA. Lines: 69 In article <12920043@acf4.NYU.EDU> chapman@acf4.NYU.EDU (Gary W. Chapman) writes: > > Ethernet >--------------------------------------------------- > | | | > PC Novell ------------------- > Server | Ungermann-Bass | > | Terminal Server | > | running TCP/IP | > ------------------- > | | | > modem modem modem > >A PC can telnet to the terminal server in order to get a >modem to dial out of the campus. Upon reaching an external >information service, however, no protocol-based file transfer >is possible. > This situation is not uncommon. Most popular telnet client programs support little in the way of file transfer protocols such as [XYZ]modem, kermit etc... I acknowledge that our pals at 3Com have put an Xmodem capability into their telnet client but there is a better way to crack this particular nut. If your favorite communications program does go to INT 14h to do I/O to what it believes to be an async line, it will typically have no concept/support of connection initiation or termination. The network aware extensions to INT14h provide these but not all comms packages use them. Also, there are a number of different extensions to INT 14h and your comms package may only be able to use one of them. Sod's law says it will be the one that's no use in your scenario! The lesson is that it's not enough to provide an INT 14h interceptor/redirector on it's own. You need to provide an external utility that is capable of manipulating and configuring your redirector on behalf of communications programs that don't understand it. This is the tac we have taken in our TCP/IP product for DOS. Our INT 14h redirector operates over telnet/TCP connections. We implemented a superset of the "known" INT 14h extensions and added our own extensions to allow such things as TCP connection initiation/termination and telnet protocol option negotiations under program control. Of course, the only people who actually used these extensions initially were ourselves, but we "published" them and gradually the comms software vendors are starting to write drivers that support them. If you own a comms program that doesn't, we provide a seperate utility that you can use to make the necessary calls into the INT 14h TSR to initiate the telnet connections, configure them and "attach" the connections to the COMx: devices. Then, when you fire up your old copy of ProComm and it goes out to COM2:, it may actually be speaking over a binary mode telnet connection to your local Sun (or whatever...). It's easy to create little batch scripts that install the INT 14h redirector, initiate the relevant connections, fire up your comms program and then, upon exiting, close the open connections gracefully and remove the redirector from memory. Anyway, I'll shut up about our product now. As your using packet drivers I'll take a guess that your TCP comes from FTP Software. I believe they have a similar mechanism and I'm sure James/Frances will be able to fill you in on the semantics of how they achieve this..... Keith ---------------------------------------------------------------------------- Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 San Jose, California 95131 Net: keith@novell.COM ----------------------------------------------------------------------------