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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7db5fb0599fd4b76 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!g14g2000cwa.googlegroups.com!not-for-mail From: "fabio de francesco" Newsgroups: comp.lang.ada Subject: Re: TCP/IP Sockets with GNAT.Sockets Date: 2 May 2005 07:55:40 -0700 Organization: http://groups.google.com Message-ID: <1115045740.838321.306480@g14g2000cwa.googlegroups.com> References: <1115001752.291144.218410@z14g2000cwz.googlegroups.com> <427618e9$0$7743$ba620e4c@news.skynet.be> NNTP-Posting-Host: 80.181.52.213 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1115045745 8565 127.0.0.1 (2 May 2005 14:55:45 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 2 May 2005 14:55:45 +0000 (UTC) In-Reply-To: <427618e9$0$7743$ba620e4c@news.skynet.be> User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g14g2000cwa.googlegroups.com; posting-host=80.181.52.213; posting-account=Lp02jQ0AAABMd3TAghNf0TM2YBZqD_JE Xref: g2news1.google.com comp.lang.ada:10874 Date: 2005-05-02T07:55:40-07:00 List-Id: Adrien Plisson wrote: > fabio de francesco wrote: > > Hello, > > hello ! > > > Today is the first time I try to use sockets in Ada programs, even if I > > have some practical knowledge of programming with TCP/IP sockets in C. > > Because I didn't find any better tutorial on working with GNAT.Sockets > > I am relying on comments in file g-socket.ads from GCC/GNAT sources > > where there is not a complete and detailed coverage of the subject. > > > > (1) Do you know any better tutorial? > > personnally, no. the GNAT reference manual says: > "The chapter here simply gives a brief summary of the facilities > available. The full documentation is found in the spec file for the > package. The full sources of these library packages, including both > spec and body, are provided with all GNAT releases." > so, you can rely on the comments in g-socket.ads (which contains some > full examples). >>From my message: "...I am relying on comments in file g-socket.ads from GCC/GNAT sources...". Sorry for my poor English, I know that sometimes I'm unable to express clearly, but I had already done exactly what you now suggest. > also, the behavior is identical to other sockets > implementation (C, Python, or others) so don't hesitate to read > manuals for other languages. I also said I already know how to program with sockets in C. > the only big difference is in Streams, which is Ada specific... This is the only problem I wrote I had. I didn't know how to use Send_Socket() and Receive_Socket() because the specs say they take "Stream_Element_Array" and "Stream_Element_Offset" as parameters. If you read g-socket.ads you won't find any usage example either of the above mentioned functions or related parameters. > [...] > > I hadn't too many problems with exchanging messages and everything > > works. The problem is that I was only able to use Streams for > > communicating between them and I can't understand at all how to use > > Receive_Socket() and Send_Socket() because they use > > "Stream_Element_Array" and "Stream_Element _Offset" in place of > > Strings. I know that by using Streams they can't communicate with C > > programs and I've read that Streams are everything but efficient. > > streams are not specially inefficient (to the contrary, my dear). the > problem is that many people do not clearly understand them ! That was what I have found by searching and reading this NG through Google for help in using them right before posting. > so let's explain Ada streams: > > streams are defined as a tagged record in Ada.Streams, which is to be > derived in order to implement stream specific behavior: how to send or > receive data from stream. Streams define 2 procedures for reading and > writing data onto them. on this side of streams, data are represented > as Stream_Element grouped in Stream_Element_Array. a single > Stream_Element may represent a byte you send over the network for > example. > > at this end of streams, there is no data type: what is important is > the type of streams you manipulate. > > on the other end, you are concerned with data types you read from or > write to stream, but not with the type of streams. on this end, every > streams are equal, may it be file, socket, or anything else. this is > achieved through stream oriented attributes: 'Read, 'Write, 'Input and > 'Output. those attributes allow you to read or write a specific data > type from/to a stream. for example: Integer'Input( S ) will read an > integer from the stream S (whatever stream type S is). the behavior of > those attribute may be overriden through an attribute definition clause. > > at this end of streams, there is no stream type: what is important is > the type of data you manipulate. > > in fact, stream attributes are kind of double-dispatching > operations... at the light of this explaination, you should re-read > ARM95 13.13, and may better understand them. Thank you for this detailed explanation. > so, now you understand this, you may ask yourself if you really need > to use Receive_Socket() or Send_Socket(): they are intended to > programmers writing their own stream attributes... (note that this > could be useful to communicate with a C program through socket streams). This is exactly the problem that I have overcome with the help I've had from Eric Jacoboni. Both my client and server programs didn't work at exchanging messages with C programs. After searching the web I discovered I had to use Receive_Socket() and Send_Socket() in order to get over that problem. S : String := "Hello"; SEA : Stream_Element_Array(1..S'Length); for SEA'Address use S(S'First)'Address; Last : Stream_Element_Offset; Send_Socket( Socket, SEA, Last ); This is not exactly what someone can find in a Python or C manual. :-) You're right about the fact that the fault is mine for not knowing Streams while a Socket package isn't required to give any explanations on the usage of a subject that is not so closely related. Anyway the package authors cover about 350 lines with an procedure example only using Streams, without ever saying why and when you should sometimes choose Receive_Socket() and Send_Socket() in place of Streams. > i hope this explaination clarified things a bit and was useful to you > (or others)... language lawyers will surely push it a little bit further. > > -- > rien Thanks, it helped a lot to make me to understand Streams. I hope this time I have been able to make myself clear. fabio de francesco