UDP networking with Ada

[Peter C. Chapin]

I have an interest in doing some network programming in Ada using UDP. I
assumed I could use GNAT.Sockets but in reading the specification of
that package it appears that it only supports TCP. I browsed around the
various other GNAT packages but I didn't see anything for UDP and now
I'm wondering what my options are.

I assume Florist probably would work on Unix-like systems and Win32Ada
would work on Windows systems (haven't looked at them in detail), but I
was hoping for something cross-platform "out of the box."

Or maybe I'm misunderstanding what I see with GNAT.Sockets?

Peter

[Randy Brukardt]

"Peter C. Chapin" <PCh...@vtc.vsc.edu> wrote in message
news:SL-dnUB_sIR...@giganews.com...

>I have an interest in doing some network programming in Ada using UDP. I
>assumed I could use GNAT.Sockets but in reading the specification of that
>package it appears that it only supports TCP. I browsed around the various
>other GNAT packages but I didn't see anything for UDP and now I'm wondering
>what my options are.

NCSockets has a "datagram" type (which uses UDP). I don't know how
well-tested it is, I think I used it once for some DNS experiments (but I'm
sure that the TCP code has been tested much more).

NCSockets is a descendant of Claw.Sockets; there are of course Windows
versions and there is an unfinished 64-bit Linux version (started by Tero
K.) that will get a lot more work in the next few weeks as I'll be using it
to port Ada-Auth's server to a new Linux box.

Randy.

[an...@att.net]

Now, most of GNAT's add-on packages like Florist uses TCP. But
GNAT.Sockets does supports both TCP and UDP protocols. And I do
have a few examples that uses UDP.

-- Create an UDP socket and I/O channel
Create_Socket ( Server_Socket, Family_Inet, Socket_Datagram ) ;
Server_Address := ...
Server_Channel := Stream ( Server_Socket, Server_Address ) ;

-- For data transfer use the attribute "Input" and "Output"
Data := Character ' Input ( Server_Channel ) ;
Unsigned_32 ' Output ( Server_Channel, Response ) ;

-- Normal termination
Close_Socket ( Server_Socket ) ;

Note:
1) At the movement GNAT only uses IP version "4". Trying to
bind a ipv6 socket will generate an exception error. May be AdaCore
will update GNAT.Sockets to allow "6" by their 2013 release date.
Some time between May and July.

2) In using selection calls. The Create_Selection routine creates
two additional sockets that are not used. This might be a problem,
depending your IP security sub-systems.

[Simon Wright]

Add note 3: don't try to use Ada stream aspects (Read, Write) with GNAT
sockets. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9535

[Dmitry A. Kazakov]

On Thu, 07 Mar 2013 19:50:51 -0500, Peter C. Chapin wrote:

> I have an interest in doing some network programming in Ada using UDP. I
> assumed I could use GNAT.Sockets but in reading the specification of
> that package it appears that it only supports TCP.

[...]

> Or maybe I'm misunderstanding what I see with GNAT.Sockets?

GNAT.Sockets work perfectly well with UDP. We are using them extensively,
e.g. for the XCP protocol, wich is UDP.

You go:

Create_Socket
Set_Socket_Option (if needed)
Bind_Socket
Receive_Socket (to receive packets)

As Simon said, don't use streams. It does not make much sense with UDP
which is packet-oriented.

If you want streams crossing packet borders you must create a stream object
of your own on top of the packets, and after you ordered packets (UDP does
not guarantee that send and receive orders are same) and resent missing
ones (UDP does not guarantee delivery).

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Jacob Sparre Andersen]

Peter C. Chapin wrote:

> I have an interest in doing some network programming in Ada using
> UDP. I assumed I could use GNAT.Sockets but in reading the
> specification of that package it appears that it only supports TCP.

I've used GNAT.Sockets for UDP, and it seems to work. You are welcome
to take a look at my (partial) UDP-based Tron implementation:

http://repositories.jacob-sparre.dk/tron

Greetings,

Jacob
--
"Look! Ugly one-horned mule."

[Simon Wright]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:

> If you want streams crossing packet borders you must create a stream
> object of your own on top of the packets, and after you ordered
> packets (UDP does not guarantee that send and receive orders are same)
> and resent missing ones (UDP does not guarantee delivery).

And consider whether you might not as well have used TCP in the first
place!

[Stephen Leake]

"Peter C. Chapin" <PCh...@vtc.vsc.edu> writes:

GNAT.Sockets has this:

type Mode_Type is (Socket_Stream, Socket_Datagram);

...

procedure Create_Socket
(Socket : out Socket_Type;
Family : Family_Type := Family_Inet;
Mode : Mode_Type := Socket_Stream);

Datagram would be UDP.

I think I've used that once or twice.

--
-- Stephe

[Dmitry A. Kazakov]

Yes. UDP is wrong choice, almost always. For multicast purposes there exist
stream-oriented protocols which supersede UDP, e.g. PGM. So, except for
communication to legacy devices and LAN broadcasts UDP should never be
used.

[Peter C. Chapin]

On 03/08/2013 01:47 AM, an...@att.net wrote:
> Now, most of GNAT's add-on packages like Florist uses TCP. But
> GNAT.Sockets does supports both TCP and UDP protocols. And I do
> have a few examples that uses UDP.
>
> -- Create an UDP socket and I/O channel
> Create_Socket ( Server_Socket, Family_Inet, Socket_Datagram ) ;
> Server_Address := ...
> Server_Channel := Stream ( Server_Socket, Server_Address ) ;
>
> -- For data transfer use the attribute "Input" and "Output"
> Data := Character ' Input ( Server_Channel ) ;
> Unsigned_32 ' Output ( Server_Channel, Response ) ;
>
> -- Normal termination
> Close_Socket ( Server_Socket ) ;

Good to know! I read these comments in the specification:

type Socket_Type is private;
-- Sockets are used to implement a reliable bi-directional
point-to-point,
-- stream-based connections between hosts.

and just assumed datagram sockets were not supported. That's what I get
for reading comments, I guess! But now I also see:

type Mode_Type is (Socket_Stream, Socket_Datagram);

-- Stream sockets provide connection-oriented byte streams. Datagram
-- sockets support unreliable connectionless message based
communication.

So I think I'm good to go.

Thanks.

Peter

[Peter C. Chapin]

On 03/08/2013 07:12 AM, Dmitry A. Kazakov wrote:

> Yes. UDP is wrong choice, almost always. For multicast purposes there
exist
> stream-oriented protocols which supersede UDP, e.g. PGM. So, except for
> communication to legacy devices and LAN broadcasts UDP should never be
> used.

UDP is a good choice for simple request/response protocols where both
the request and the response are small enough to fit into a single
datagram. For example: DNS. Also in this situation the overhead of TCP
might be considered undesirable.

Peter

[Dmitry A. Kazakov]

On Fri, 08 Mar 2013 07:17:32 -0500, Peter C. Chapin wrote:

> On 03/08/2013 07:12 AM, Dmitry A. Kazakov wrote:
>
> > Yes. UDP is wrong choice, almost always. For multicast purposes there exist
> > stream-oriented protocols which supersede UDP, e.g. PGM. So, except for
> > communication to legacy devices and LAN broadcasts UDP should never be
> > used.
>
> UDP is a good choice for simple request/response protocols where both
> the request and the response are small enough to fit into a single
> datagram.

No, because of non-delivery and ordering issues.

> For example: DNS. Also in this situation the overhead of TCP
> might be considered undesirable.

Which is largely an urban legend.

1. Once the non-delivery, acknowledge, ordering etc issues solved, UDP
would likely have bigger overhead than TCP. Remember that some parts of
those in the case TCP are implemented directly by the hardware. Whereas for
UDP it is the application = the CPU, which must do all the job.

2. There is no OS under which you could choke 1000 Base, even 100 Base
Ethernet on a P2P connection.

3. We did measurements actually. Latencies of TCP/IP (with NO_DELAY) and
UDP are basically same under VxWorks and Windows.

UDP could be used for connectionless (=> stateless) stuff which is
basically limited to network announcements.

[Tero Koskinen]

My public changes are available at
https://bitbucket.org/tkoskine/not-claw-sockets-linux-x86

Don't be fooled by the repository name, the code works (barely) only
on x86_64 (not on i386).

And while I remember, I think I hacked select so that it works with only
one socket at time... (It is quite hard to create a binding to select(2),
especially if you want it to work on multiple architectures without code
changes.)

>
> Randy.
>
>


--
Tero Koskinen - http://iki.fi/tero.koskinen/

[Kevin K]

You have to consider what you are trying to do in determining whether to use UDP or TCP. It isn't the case that almost never do you want to use UDP.

For example, if you are wanting to interoperate with a process that is defined UDP, you have to use that.

For slow networks with measurable packet loss, TCP can be a poor choice since a missing packet forces the retransmission of all data after a missing packet.

TCP isn't a good mechanism to send to multiple recipients at the same time on slow nets. UDP can be broadcast in local nets while TCP won't handle this.