networking support?

networking support?

[Oliver Kowalke]

Hi,
does Ada support IPsec (key management sockets)? How is io-demultiplexing
used (select, epoll, kqueue, /dev/pool,...) used?

regards,
Oliver

Re: networking support?

[Georg Bauhaus]

Oliver Kowalke schrieb:
> Hi,
> does Ada support IPsec (key management sockets)? How is io-demultiplexing
> used (select, epoll, kqueue, /dev/pool,...) used?

These being OS functions, you probably have interfacing
packages for your compiler. For some, you might be able to use
POSIX packages;  others, such as access to /dev/anything are
really OS specific, not typically built into
any programming language, but rather available as
library calls.  In case you want to call them directly,
as you would using C, just call them, after, say,

   function select
     (nfds: C.int, ... etc etc ...) retrun C.int;

   pragma Inport(C, select);

Re: networking support?

[Jacob Sparre Andersen]

Oliver Kowalke wrote:

> does Ada support IPsec (key management sockets)?

Yes and no.

ISO/IEC 8652:2007 does not mention IPsec, so in a sense it isn't
supported directly in Ada.

But you can write programs using IPsec in Ada.

> How is io-demultiplexing used (select, epoll, kqueue, /dev/pool,...)
> used?

I can't remember.  You'll have to look it up.  (Or wait for someone
else to answer.)

Greetings,

Jacob
-- 
"Experience" is what we have that enables us to recognize a
mistake when we make it again.

Re: networking support?

[Oliver Kowalke]

Georg Bauhaus wrote:

> Oliver Kowalke schrieb:
>> Hi,
>> does Ada support IPsec (key management sockets)? How is io-demultiplexing
>> used (select, epoll, kqueue, /dev/pool,...) used?
> 
> These being OS functions, you probably have interfacing
> packages for your compiler. For some, you might be able to use
> POSIX packages;  others, such as access to /dev/anything are
> really OS specific, not typically built into
> any programming language, but rather available as
> library calls.  In case you want to call them directly,
> as you would using C, just call them, after, say,
> 
>    function select
>      (nfds: C.int, ... etc etc ...) retrun C.int;
> 
>    pragma Inport(C, select);

Because I'm novice to Ada is it true that I can call C functions and C++
classes from Ada?
If yes - what is the prefered usage: should I implement functionality (for
isntacne networking) in C++ classes and call them from Ada or use the
C-functions (system calls) and implement the classes/behaviour in Ada (get
benefits from Ada's safety)?

Oliver

Re: networking support?

[Georg Bauhaus]

Oliver Kowalke schrieb:
> is it true that I can call C functions and C++
> classes from Ada?

You can call C functions (and probably anything that
uses C calling conventions, on the same platform).
Have a look at Interfaces.C.  This package is defined
by the Ada language.

A similar feature exists for C++ classes, at least
with some compilers, covering some amount of C++.

> If yes - what is the prefered usage: should I implement functionality (for
> isntacne networking) in C++ classes and call them from Ada or use the
> C-functions (system calls) and implement the classes/behaviour in Ada (get
> benefits from Ada's safety)?

How would your program benefit from first wrapping system
functions (that use C conventions) in C++ classes only for
having to match Ada's O-O types and C++'s O-O types in
a second step?
Seems like an artificial setup to me.

Re: networking support?

[anon]

If you are using GNAT  

then you can use "GNAT.Sockets" for High-level network programming and 
"GNAT.Sockets.Thin" for the low-level OS calls like select routine.

As for other routines, you must use an "pragna import" statement, because 
Ada does not directly support these calls.


In <gibghn$2pr$1@online.de>, Oliver Kowalke <oliver.kowalke@gmx.de> writes:
>Hi,
>does Ada support IPsec (key management sockets)? How is io-demultiplexing
>used (select, epoll, kqueue, /dev/pool,...) used?
>
>regards,
>Oliver

Re: networking support?

[Jeffrey R. Carter]

Georg Bauhaus wrote:
> 
>    function select
>      (nfds: C.int, ... etc etc ...) retrun C.int;
> 
>    pragma Inport(C, select);

Since "select" is an Ada reserved word, this is unlikely to work.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: networking support?

[Georg Bauhaus]

Jeffrey R. Carter schrieb:
> Georg Bauhaus wrote:
>>
>>    function select
>>      (nfds: C.int, ... etc etc ...) retrun C.int;
>>
>>    pragma Inport(C, select);
> 
> Since "select" is an Ada reserved word, this is unlikely to work.

Ouch!  And "Inport" neither...
Formal likelihood really does include the value 0.0.

Re: networking support?

[Maciej Sobczak]

On 18 Gru, 13:47, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:

> How would your program benefit from first wrapping system
> functions (that use C conventions) in C++ classes only for
> having to match Ada's O-O types and C++'s O-O types in
> a second step?
> Seems like an artificial setup to me.

Except that a lot of things in the C world (especially in the system
APIs) are defined in header files as preprocessor constants, optional
or even unofficial structure fields or field order within a struct -
all this means that the binary layout of data structures is a big
question mark. This problem is particularly notorious with network
services.
There is no way to reasonably interface with all this mess from Ada
and having a wrapper layer that fixes some of this optional/unofficial/
ordering stuff for the Ada part is a valid option.
Now the question is how thick this adapter layer should be - and here
a layer that does a bit of lifetime management or error reporting in
addition to just parameter passing is also a valid solution.
Then you might discover that all the work that is done in this
adapting layer can be reused in C++ projects as well (it is a low-
hanging fruit, so why not benefit from it?) and you end up with a
regular C++ library that encapsulates some system services and is used
from the Ada program.
There is nothing artifical in it - it starts with a fundamental
feasibility issues and ends up with simple economy.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: networking support?

[Oliver Kowalke]

Maciej Sobczak wrote:

> On 18 Gru, 13:47, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> 
>> How would your program benefit from first wrapping system
>> functions (that use C conventions) in C++ classes only for
>> having to match Ada's O-O types and C++'s O-O types in
>> a second step?
>> Seems like an artificial setup to me.
> 
> Except that a lot of things in the C world (especially in the system
> APIs) are defined in header files as preprocessor constants, optional
> or even unofficial structure fields or field order within a struct -
> all this means that the binary layout of data structures is a big
> question mark. This problem is particularly notorious with network
> services.
> There is no way to reasonably interface with all this mess from Ada
> and having a wrapper layer that fixes some of this optional/unofficial/
> ordering stuff for the Ada part is a valid option.
> Now the question is how thick this adapter layer should be - and here
> a layer that does a bit of lifetime management or error reporting in
> addition to just parameter passing is also a valid solution.
> Then you might discover that all the work that is done in this
> adapting layer can be reused in C++ projects as well (it is a low-
> hanging fruit, so why not benefit from it?) and you end up with a
> regular C++ library that encapsulates some system services and is used
> from the Ada program.
> There is nothing artifical in it - it starts with a fundamental
> feasibility issues and ends up with simple economy.

my intention was to call some boost libraries (www.boost.org).
I'm not sure if C++-templates can be accessed/used by Ada.

regards,
Oliver

Re: networking support?

[Georg Bauhaus]

Maciej Sobczak wrote:
> This problem is particularly notorious with network
> services.

OK.  (One might wonder, as an aside, why we still have to live
with this mess. Even in C, there is "inline", there is splint
for motivating abstraction, etc.  A C-to-Something translator
where Something forces abstraction, or at least fixes the vagueness
inherent in C data layout, will solve many problems...)

> There is no way to reasonably interface with all this mess from Ada
> [...] you end up with a
> regular C++ library that encapsulates some system services and is used
> from the Ada program.

Granted, some C libraries expose and require the use of internal
data structures, even slippery ones, and very likely a C++ abstraction
will handle the data just like the C compiler.
What remains is a different kind of mess (or fun, depending on
the perspective):  We have to start from some "clever"
traditional C brilliance.  Then chain two languages that somehow
trigger better abstractions. Or that provide more clear cut data
definitions. In a sense, then, the motto of the profession
becomes shrug and preserve, either way.

Re: networking support?

[Maciej Sobczak]

On 20 Gru, 00:05, Oliver Kowalke <oliver.kowa...@gmx.de> wrote:

> my intention was to call some boost libraries (www.boost.org).
> I'm not sure if C++-templates can be accessed/used by Ada.

A significant part of the Boost libraries are template-based libraries
entirely defined in their header files. There is even no object code
to link to until you instantiate the target templates.
Unfortunately there is no way to directly use them from Ada.
Which Boost libraries are you interested in?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: networking support?

[Oliver Kowalke]

Maciej Sobczak wrote:

> On 20 Gru, 00:05, Oliver Kowalke <oliver.kowa...@gmx.de> wrote:
> 
>> my intention was to call some boost libraries (www.boost.org).
>> I'm not sure if C++-templates can be accessed/used by Ada.
> 
> A significant part of the Boost libraries are template-based libraries
> entirely defined in their header files. There is even no object code
> to link to until you instantiate the target templates.
> Unfortunately there is no way to directly use them from Ada.
> Which Boost libraries are you interested in?

DateTime
Filesystem
System
Interprocess
(Regex)

Re: networking support?

[Maciej Sobczak]

On 21 Gru, 18:57, Oliver Kowalke <oliver.kowa...@gmx.de> wrote:

> > Which Boost libraries are you interested in?
>
> DateTime
> Filesystem
> System
> Interprocess
> (Regex)

I think that for these libraries your best option is to write simple
wrappers with extern "C" interface (that is, C wrappers) and pragma
Import that interface to Ada.

Note also that a significant part (if not all) of this is already
available in Ada in the standard library or in the GNAT library - it
might be easier and more natural to use what Ada offers first before
reaching out to C++ libraries.
I would go for interfacing to an existing C++ library only when
something much more specialized is involved. Numeric computation or
communication infrastructure are possible examples.
A database library would be another example, see SOCI-Ada linked
below.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada