From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2d69f4a8070dd707,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-30 22:01:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!panix!newsfeed.media.kyoto-u.ac.jp!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail Message-ID: <3ED83712.8090905@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Ada.Networks.Sockets hierarchy for standardization? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 31 May 2003 01:01:06 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1054357575 24.150.168.167 (Sat, 31 May 2003 01:06:15 EDT) NNTP-Posting-Date: Sat, 31 May 2003 01:06:15 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:38173 Date: 2003-05-31T01:01:06-04:00 List-Id: For discussion: I have thrown together this evening a more formalized view of some "chicken scratching" I did on my train commute home this evening. The diagram is available at my web site (see PDF link further on). While we're on the subject of sockets and URLs, here is a shameless plug 8-) for my "Linux Socket Programming by Example" book (sorry folks, its C/C++ based): http://www.amazon.com/exec/obidos/ASIN/0789722410/qid%3D996033092/104-8302379-1659946 Before jumping right to the diagram, please read the following first (otherwise you might GOL (Gasp Out Loud)). IIRC, earlier discussions centered around something rather simple like Ada.Sockets as providing all/mostly all of the basic needs of application programmers. I am going to propose something a little bit different, but I do believe that this requirement for simplicity should be accomodated. But I believe starting off too simple would be a great mistake, and severely limit what could otherwise be a successful, and nearly complete longer term model for Ada. To address the "simple requirements" class of applications, I have included in the diagram the package Ada.Networks.Simple, for lack of a better name at the moment. Maybe "Basic" would be better. This package can then use renames and other basic Ada techniques to pull together all of the basic facilities into one place, that would otherwise have to be pulled from a number of other packages and child packages (a la cart). Now it is probably safe to view the diagram: http://home.cogeco.ca/~ve3wwg/Ada.Networks_Hierarchy.PDF Now you're probably wondering why we need all these "flippin packages"? Here's my reasons below: You will need to lump many aspects of networking under one umbrella. There is much more to sockets than just sockets however. I mentioned the need for name services in an earlier thread. For this reason, and others, I think we will need to have a top level Ada.Networks package to bring the common elements together. In my book, I spend an entire chapter showing how to form socket addresses. This is important because it is a somewhat arcane thing in C, and the many forms of addresses makes this essential to cover. I also believe that Ada will need a top level Ada.Networks.Addresses package from which to derive child packages for IPv4, IPv6, X.25, AX.25, AppleTalk and other addresses (also to derive from abstract tagged records etc.) To allow for extension and additions, I propose that we then add child packages in the form Ada.Networks.Addresses.IPv4, IPv6 etc. Internet addresses are usually known by names these days, rather than their IP#'s as in the years gone by. Hence the need for the Ada.Networks.Name_Services top level package. Then its subdivided by protocol (I show Internet and X.500). BTW, I am not suggesting that all of these need to be part of any initial "offering". But I do believe we need to make room for them ;-) Of course, there is the all important Ada.Networks.Sockets top level package. I can envision 3 child packages, where the most important one is the Berkeley sockets, and the XTI sockets. Some may want to also add in WinSock, though now that XP supports Berkeley sockets, there may not be any real need for this anymore. I don't want it, but I left a spot for it. These packages would concern themselves strictly with the creating, binding, listening, accepting and other socket basic functions. The Socket_Type would act as a "handle". I don't see I/O functions being included here, but this is obviously open to discussion. Of course, security is important, and I am not so sure that I have properly planned for that here. I have suggested that we need a Ada.Networks.Filters which includes a child package SSL, that can be "pushed" onto an open socket similar to the way AT&T UNIX streams worked. The Ada.Networks.Protocols and their child packages (particularly Internet) provided constants that pertain to the types of sockets required. These packages would have constants that select TCP, IP, UDP, ICMP etc. when creating a socket. Other protocols of course are possible, and Linux I know supports X.25 and the amateur radio AX.25 as two other examples. The package Ada.Networks.Services.Internet is what you would use to map http to port 80, ftp to port 21, etc. These are covered by the services database UNIX calls, and map well known services to port numbers. I have thrown in Ada.Networks.XDR to provide endian neutral communications a la RPC in the C world. Perhaps this can be used again in "push" fashion on a socket. The placement and organization of this in large part depends upon a successful implementation. TBD. Ada.Networks.Streams, as I see it, would take a Socket_Type and return some Stream_Type that you could perform various I/O types of operations on. It would also include a function to re-expose Socket_Type, so that calls like shutdown(2) can be performed, if you were only given a Stream_Type in a subprogram, for example. From Ada.Networks.Streams, I think you could branch out into varous things like XML, SOAP, ftp, http etc, and perhaps Text_IO belongs here (I am not sure about this yet though). But I think this can work. Finally, package Ada.Networks.Simple would then pull together in one place, the basic elements out of all of the packages in Red, that are necessary for the most basic TCP/IP application needs. This is like using Simon Wright's fine Booch Components, which is a bit tricky to instantiate. I use my own "wrapper generics" to do the same thing that Ada.Networks.Simple should be able to do, ie, to make it possible to instantiate everyting in one "go". The Ada.Networks.Simple would be a "wrapper package" for simplicity's sake. I see the packages in red as being essential to anything that is close to being complete. The rest would be gravy, but these are things that I think we should shoot for. Keep in mind that the C world already has access to all of these things, without any further effort. Because of this, I think we should support what is possible. Most of this stuff is just writing careful thick binding support. Doing the XDR part portability, is tricky, but the payback is there. What do you think? -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg