home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / datacomm / 7750 < prev    next >
Encoding:
Text File  |  1992-11-17  |  10.7 KB  |  303 lines
  1. Newsgroups: comp.sys.amiga.datacomm
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!rpi!ghost.dsi.unimi.it!ICIL64.CILEA.IT!LABENRSA
  3. From: labenrsa@ICIL64.CILEA.IT
  4. Subject: amiga netwrk stdrd api
  5. Nntp-Posting-Host: icil64.cilea.it
  6. Sender: news-mail@ghost.dsi.unimi.it (News mail user)
  7. Organization: CILEA - v R. Sanzio 4 - Segrate - ITALY
  8. Date: Wed, 18 Nov 1992 11:21:17 GMT
  9. Message-ID: <1992Nov18.112117.9143@ghost.dsi.unimi.it>
  10. Reply-To: labenrsa@ICIL64.CILEA.IT
  11. Lines: 290
  12.  
  13.  
  14.  
  15. Amiga networking software is starting to bloom. Sadly, there seems to be
  16. very little concern about the _integration_ of networking software in
  17. the Amiga OS environment. So far, SANA has only addressed API standardization
  18. at the data link layer (or whatever they call it in SANA), and even that
  19. specification is not being followed by most networking software.
  20.  
  21. To provide both user and application programmer with a consistent
  22. networking environment, we need more than just raw ports of lots of net
  23. stacks.
  24.  
  25. Let me picture what I mean by getting a bit more technical.
  26.  
  27.  
  28. Case 1 : Network-Aware Applications and APIs
  29. ============================================
  30.  
  31. Network-aware applications use some network API directly. Two well-known
  32. examples are internet clients that use the BSD/SunOS sockets API with
  33. TCP/IP protocols and Novell NetWare clients.
  34.  
  35. In all cases where existing network stacks have been ported to the Amiga
  36. (e.g. see the socket.library), their APIs have been reproduced, with the
  37. goal to minimize the effort of porting existing software from other OSs.
  38.  
  39. Like it or not, all existing network APIs are designed to work well with the
  40. OS they were born in. Porting them over to another system often results in
  41. poor integration with the new environment, incompatibilities with the original
  42. implementation and resorting to gory hacks to get things working.
  43.  
  44. For example, BSD sockets fit in very well in BSD/SunOS systems or lookalikes
  45. *because they're designed as part of that system*. They simply clash with
  46. the Amiga programming model (signal/message IO vs. file descr. IO + fork()).
  47. When implementing socket applications on the Amiga, you may have to change
  48. quite a lot here and there. In the end, it's still some work and you'll end
  49. up with some pretty nasty code (compared to 'good' Amiga code).
  50.  
  51. Seriously, the only applications that really benefit from an
  52. 'as-close-to-bsd-as-possible' approach are the standard internet servers and
  53. their related console-oriented clients, which altogether stink when compared
  54. to standard Amiga applications. Any serious Amiga TCP/IP package will want
  55. to have them reworked from the ground up.
  56.  
  57. So, why not go for an All-Amiga networking API?
  58.  
  59. Please note that changing the API has nothing to do with the protocol you
  60. are using. You should be able to use TCP/IP, or any other transport, from
  61. a standard (well designed) Amiga network API.
  62.  
  63. Also note that it wouldn't be TOO hard to recode a socket (or other API)
  64. application for a standard Amiga API. In fact the Amiga API would more or
  65. less provide the same sort of services (connect/disconnect/accept/send/receive)
  66. only through a *cleaner* interface.
  67.  
  68. Imagine an implementation layered like this:
  69.  
  70.           ------------------------------------------
  71.           |                Applications            |
  72.           ------------------------------------------
  73.  
  74. -----------             -------------------
  75. DOS, Exec,|. ...........| network.library |                Standard API
  76. -----------             -------------------
  77.                -----------   ----------   ----------
  78.                | Internet|   | Decnet |   | Novell |       Protocol stacks
  79.                -----------   ----------   ----------
  80.  
  81.              -----------   ----------   ---------------- 
  82.              | Ethernet|   |  SLIP  |   | Exec MsgPort |  SANA-2 dev drivers
  83.              -----------   ----------   ----------------
  84.  
  85. Expected benefits :
  86.  
  87. 1 - All applications that go through the network.library would be able
  88.     to operate over any protocol stack.
  89.  
  90. 2 - Let users configure their networking setup easily and even
  91.     *choose* what transport to use for some services.
  92.  
  93. 3 - Multiple protocol stacks would be able to operate on the same
  94.     interface (already a goal of SANA).
  95.  
  96. 4 - Maximize robustness and efficiency of Amiga-specific software in
  97.     a networking environment.
  98.  
  99.  
  100. Expected problems:
  101.  
  102. 1 - Flame wars concerning the API calls (aw, come on... ;> )
  103.  
  104. 2 - How do we provide a clean interface to protocol-specific services
  105.     and options? (For options, taglists may work.)
  106.  
  107. 3 - Efficiency: net sw is heavy, and having one more implementation layer
  108.     isn't going to help.
  109.  
  110.  
  111. Now let me picture how a sample Amiga network application should work. This
  112. is NOT an API design (yet), but should clarify what I have in mind. No
  113. flames, please. Comments are welcome.
  114.  
  115.  
  116. /*
  117.  * Sample Amiga networking application. -- connectionless client.
  118.  *
  119.  * use HYPOTHETICAL (how do you spell it?) network.library
  120.  * PSEUDO-C PSEUDO CODE : all checks removed
  121.  */
  122.  
  123. #include <sana.h>
  124. #include <libraries/network.h>
  125.  
  126. void main (int argc, char *argv[])
  127. { 
  128.     NetProtocolSpec   default_prot = {"netbios", 0,0}; /*...or whatever */
  129.     NetProtocolSpec   *pr_list, *pr_chosen;
  130.  
  131.     NetProtocol       *pr;
  132.  
  133.     NetObject         *nobj;
  134.     NetAddress        *target_addr;
  135.  
  136.     TEXT              target_name = argv[1];
  137.     TEXT              message     = argv[2];
  138.  
  139.  
  140.     NetBase = OpenLibrary ("network.library", 0);
  141.  
  142.  
  143.     /* open user interface, etc.... */
  144.  
  145.  
  146.     if (prompt_user_for_transport)
  147.     {
  148.         pr_list = LockProtocolList();
  149.  
  150.         pr_chosen = request_protocol (mywindow, "Choose Transport", pr_list);
  151.  
  152.         pr = OpenProtocol (pr_chosen);
  153.  
  154.         UnlockProtocolList (pr_list);
  155.     }
  156.  
  157.     else
  158.     {
  159.         pr = OpenProtocol (&default_prot);
  160.     }
  161.  
  162.  
  163.     /* open a communication endpoint (equivalent to a socket) */
  164.     nobj = NewNetObject (pr, NTAG_OBJ_FLAGS,      my_netobj_flags,
  165.                              NTAG_PROTOCOL_FLAGS, my_protocol_flags,
  166.                              .......................................
  167.                              TAG_DONE ); 
  168.  
  169.     /* find out whom we wanna talk to */
  170.     target_addr = NetResolve (pr, target, NTAG_RESOLVE_OPTS, ...., TAG_DONE);
  171.  
  172.  
  173.     /* post message to target */
  174.     NetSend (nobj, target_addr, message, strlen(message) );
  175.  
  176.     /* handle post and user interface Amiga-style */
  177.     net_sigmask = NetObjectSignal (nobj);
  178.  
  179.     mask = window_sigmask | timer_sigmask | 
  180.  
  181.     for (;;)
  182.     {
  183.         sig_received = Wait (mask);
  184.     
  185.         if (sig_received & net_sigmask)
  186.             size_read = NetRead (nobj, reply_buf, bufsize);
  187.         
  188.         else if (sig_received & timer_sigmask)
  189.             break;
  190.  
  191.         /* etc... */
  192.     }
  193.  
  194.     /* make sure we don't have any pending net I/O */
  195.     NetWaitIO (nobj);
  196.  
  197.     /* clean up */
  198.     DisposeNetObject (nobj);
  199.     CloseProtocol (pr);
  200.  
  201.     CloseLibrary (NetBase);
  202. }
  203.  
  204. A connection-oriented application would need different calls, and so would
  205. the clients. It is pointless to try to sketch them here. Basically, get
  206. the flavor of this sample and apply it to the different communication models.
  207.  
  208. The main points I want to get through are : 
  209.   1) I want to access multiple protocol stacks through the same API
  210.   2) I want the API to be *designed for the Amiga OS*, specifically
  211.      supporting synchronous and asynchronous I/O, signals & c....
  212.  
  213. ISSUES :
  214.  
  215. The example above is a complete mess, since it mixes several
  216. Amiga programming approaches. Several options are indeed available :
  217.  
  218. - Should the  network.library actually be complemented by a network.device
  219.   so that we can do I/O via Exec calls : SendIO/DoIO, etc.... ?
  220.   (this is the sort of approach used by VMS/DECNET at the nontransparent
  221.    level. I may be wrong but maybe DNET does something like this...)
  222.  
  223. - Should the network.library actually have a network.handler, so that
  224.   we can do straight AmigaDOS I/O (both packet and file-oriented) ?
  225.   This option somewhat overlays the case of 'transparent' network
  226.   communication, discussed below.
  227.  
  228. - Make it just a no-fuss library which resembles either but is none of
  229.   them (as I sort-of did in the example)?
  230.  
  231.  
  232.  
  233. Case 2 : Network-Transparent Applications
  234. ==========================================
  235.  
  236. Another big issue is the need to have standard AmigaDOS applications
  237. operate over a network transparently, without calling a networking API.
  238.  
  239. It seems that the current approach taken by most Amiga networking software
  240. works like "mount the remote file/device, then use it as if it were a
  241. local filesystem". This scheme, notably used by NFS and most MS-DOS
  242. networks, is fine for many applications, but not for all.
  243.  
  244. If the network gets very large and a lot of services are available which
  245. you will not use on a regular basis, you definitely do _not_ want to
  246. have them all mounted at all times, or to have to mount and dismount them
  247. explicitely on occasion.
  248.  
  249. For instance, suppose you have a large LAN, where a single server hosts
  250. most of the application software. You install a new release on the server
  251. and that's fine. But then you have to install a license or just a 100 byte
  252. preference file in _every client_ node. Would you want to mount them all
  253. on the server, or walk to every machine with a disk, or just sit at the
  254. server and type something like:
  255.  
  256.    -- scheme 1
  257.  
  258.    COPY mydatabase.prefs vulcan"sysadm password"::sys:preferences
  259.    COPY mydatabase.prefs juno"sysadm password"::sys:preferences
  260.    .... etc ....
  261.  
  262. Many other examples could be provided where a remote mount is unsuitable.
  263. (I know *you* would use rcp or ftp, but, once again, let me point out
  264.  I'm talking about NATIVE, non-network aware AmigaDOS sw...).
  265.  
  266. What I'm suggesting is that there should be a _standard_ syntax to reference
  267. remote file systems in a normal AmigaDOS path _without_ needing to mount
  268. them.
  269.  
  270. This access method _does not replace_ remote mounts, but rather _complements_
  271. them where they are not suitable.
  272.  
  273. Scheme 1 shows just one the many possible extended pathname syntaxes. This
  274. one is patterned after DECNET usage, and is probably very poorly chosen.
  275. If a pathname syntax extension is used, the AmigaDOS library should have
  276. the DeviceProc() (and maybe others) call patched to detect a remote
  277. filesystem specification in the path name and go through a special
  278. dos handler.
  279.  
  280. Naturally, it would be best if we could maintain the current AmigaDOS
  281. syntax and use something like this:
  282.  
  283.    -- scheme 2
  284.    COPY mydatabase.prefs "NET_DEV:node/volume/path/account=xxx/passwd=yyy"
  285.  
  286. ISSUES:
  287.  
  288.  -  Can scheme 2 be made to work with all transport protocols and
  289.     remote operating systems (which may be unix/vms/dos/....) file
  290.     specification?
  291.  
  292.  -  In case we must resort to a pathname syntax extension, which syntax
  293.     is less likely to break pathname parsers in existing software?
  294.  
  295.  
  296.                               ---- o ----
  297.  
  298.  
  299.                          Tnx for your attention
  300.  
  301. ---------------
  302. Andy Zanna                           e-mail:   SDEVAX::ZANNA@icil64.cilea.it
  303.