Path: utzoo!utgpu!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!bloom-beacon!ucbvax!HNYKUN11.BITNET!U211344 From: U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Splitting up KA9Q-net (was: Re: Anomalies with KA9Q) Message-ID: <8811091318.aa29770@Louie.UDEL.EDU> Date: 9 Nov 88 17:02:16 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 67 > Taking a linked-in TCP/UDP/IP and turning it into a separate system > service module is certainly possible; that is what we did to PC/TCP > between our 1.1 release (which worked like PC-IP) and our 2.0 release > (where the TCP etc. are in a DOS TSR). However, it is a bunch of work, > even when you are starting with something designed around a built-in > multitasker (like PC-IP). It might be easier if you have a real O/S > handy (in this area, DOS has very little help to offer). > > The level of effort depends on whether Phil has been planning for this > sort of thing in his in-progress version. If not, it could easily take > a man-year or more. > > James VanBokkelen > FTP Software Inc. Of course I have thought about the matter myself, and I think that given a proper message passing system with (at least pseudo-) multitasking it should not be too difficult. If you are stuck with msdos, you might have some work to do. What I personally have in mind is the following. Suppose you have a server program, such as SMTP. In the current (old) version, the server does some initialization, opening a TCP connection. With that connection it specifies some upcalls. Then it returns to the main loop of the program. Most of the work is then done via these upcalls. In the end, when the user of the machine decides to shut down the server, some de-initialization is done. Note that these upcalls are actually a hack that try to do event- driven programming on a system without something like message-passing. Now if you take a system WITH message passing, you could do the following: The server wishes to open a TCP connection. It calls a function such as tcp_open(), given suitable parameters. This function packs the parameters into a message, which is sent to the TCP system. While the server waits for the reply, TCP finds out what action was requested, carries it out, and returns the result to the server. Back to the server (the user program). Having opened the connection, it enters a wait state to wait for events to happen (messages coming in). Data can arrive, data we wanted to be sent can have arrived at the other side, and the server acts appropriately. This is what gets simulated by the upcalls, with the difference that when you use upcalls the actions are, in fact, performed in the wrong context. (Everyone must agree that it is ugly to do things to be done by an SMTP server from the TCP layer). I already have sketched (for myself) how I would implement such a scheme using message passing on the Amiga. (The Amiga is a system in which many system functions are used by sending mesages). It should even be possible to write it in such a way that (with proper care of course) the same sources can be compiled on a PC to the single, huge, monolithic, non multitasking program the way it is now, but used on the Amiga to split different applications into different executables. (but then you have to accept some uglyness in the upcall/event handling conversion). If anyone is intested in seeing my code I could consider emailing it to you. Note, however, that though the idea is 'portable', the actual implementation looks quite Amiga-specific. Freely_Distributable=Greetings(Not_For_Any_Commercial_Purpose)-> Olaf.Seibert; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ Let me tell you that I disclaim anything you care to name +++ --- Olaf Rhialto Seibert the Marvellous --- U211344@hnykun11.bitnet --- 7167 BYTES FREE *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*