BEAME@MCMASTER.BITNET (03/04/88)
>I don't mind the idea of sockets as an interface; We did an emulation of >them for our 2.0 release, primarily to allow existing Berkeley code to be >ported to DOS. I have to agree that I don't mind sockets for an interface, but I don't feel that it can be the only interface because of the inability to provide for ansyc. interrupts{ At Beame & Whiteside Software LTD. we have our own socket emulation library. Our sockets: Support read/write,as well as descriptor reading/writing using standard C routines Support select(), on all C channels Support ioctl() (some calls) Support send(), sendto(), recv() and recvfrom(). Support listen(). Support get/setsockopt(), connect(), bind() ... gethostbyname() ... Support setitimer(),getitimer(),alarm() >What we have done is define our own native-mode interface, >standardized around register contents in an interrupt instruction. This >has copious asynch facilities, and is broad enough that the socket emulation >was relatively simple to do on top of it. This is much the same for our code. I have been wondering if it would be possible to have the select() routine on initial activation, terminate and stay resident. Then when a network event occurs, have the process "called" within the select() routine and have it continue normal processing of the code. - Carl Beame Beame@McMaster.BITNET
karl@TRWIND.IND.TRW.COM (Karl Auerbach) (03/04/88)
How much recursion do you allow within the asynchronous part of the lower level service interface? It seems important that the context of an asynch handler be rich enough to let me do sends/closes/ aborts/etc. When defining the asynchronous service do you define how much stack space is available (or does the user have to set his own stack?) What about register saving/restoreing -- who is responsible? And is the user allowd to open up interrupts (assuming they were disabled.) And how much base OS function is permitted in the asynch handler (e.g. can I open a file, muck around in it for a while [long enough that other net packets have probably arrived]?) After having worked with various forms of asynch handlers, I find these less interesting issues to be where the implementation problems occur. By-the-way, I think this discussion of interfaces is important. Thanks to those of you who are trying to get the ball rolling again. More by-the-way, is the goal a binary interface or a source code interface? (I prefer the former.) --karl-- (Karl Auerbach)
jbvb@VAX.FTP.COM (James Van Bokkelen) (03/05/88)
FTP Software's 2.0 asynch interface allows the following: You can make any non-blocking kernel call (including writes and closes/aborts), provided that you don't interrupt a blocked syscall of the same type from the mainline program on the same network descriptor. In other words, you can net_write from an asynch handler while the mainline is blocked in net_read on the same descriptor, and you can net_abort from the asynch handler, but don't try another net_read. We support two kinds of handlers. 1. User upcall written in assembly, that doesn't need to save registers, but does have to switch stacks. 2. C-language upcall, where the stack switch is already done, but the stack isn't awfully large (2400 bytes). Interrupts are enabled at entry to either kind. You aren't guaranteed to be synchronized with either DOS or the mainline, so you have to do your own check before you can use O/S services. In general, our asynch handlers aren't supposed to take *too* long, because you're locking out other asynch upcalls, and the kernel won't preempt your handler to do packet processing. Since our normal network descriptors are allocated from a particular program's file descriptor space, and we can't associate a PID with a system call made from an asynch handler, we require that all network descriptors used from within asynch handlers be global (unique in the system). I don't know what goals others have. We have the sockets at source-code level, and our native interrupt-based interface at binary level (you can substitute any of our various TCP/IP kernels without changing your .EXE file, if you need to change interfaces). jbvb
jbvb@VAX.FTP.COM (James Van Bokkelen) (03/05/88)
One more point about FTP's sockets: Because it is done at source-code level, the version avilable right now is for MSC 4.0, all memory models. It has been reported to work under 5.0 as well, but we don't trust that compiler for our own work yet. We have several more compiler ports in mind. Our native interface can be programmed from anything that can do an INT instruction (it was originally designed so that a protected-mode 286 language environment could call it easily). jbvb
backman@interlan.UUCP (Larry Backman) (03/07/88)
In article <8803040730.AA11717@trwind.ind.TRW.COM> karl@TRWIND.IND.TRW.COM (Karl Auerbach) writes: >How much recursion do you allow within the asynchronous part of the >lower level service interface? It seems important that the >context of an asynch handler be rich enough to let me do sends/closes/ >aborts/etc. > >By-the-way, I think this discussion of interfaces is important. >Thanks to those of you who are trying to get the ball rolling again. > >More by-the-way, is the goal a binary interface or a source code >interface? (I prefer the former.) > [] A vendors view.... I too was at the BOF for sockets in December, and wondered what had happened. We at Micom - Interlan are currently finishing a C callable socket library for our Netware TCP gateway. It provides your basic Bsd 4.3 interface ala.. s = socket ( addr_family, socket_type, protocol) bind ( s, sockaddr, sizeof (struct sockaddr) ); and so on. This approach necessitates the releaseables to be MSC .lib files and accompanying source. The user can then either link the libraries to their application, or if they are using a different development environment, recompile the source as needed. Since we are a gateway, te TCP code resides on the file server, and the application does not see packets, nor does it have to worry about asynchronous events (for the most part). We also ducked on <select> and <signal> as they don't mix well with DOS. Install your own keyboard handler, and forget about <select>. We found this the easiest way of building our apps. (FTP TELNET et. al.). Signal is ugly in DOS, there is no clean way that we have found.. Binary interface is difficult. How do you define a TSR. A full socket TSR might take 100K. Is that acceptable?a Binary may make sense for a full TCP implementation in a single machine, but makes no sense as for a gateway! So anyways, count me in on any socket religious wars that ensue. It should be fun.. larry Backman Micom - Interlan