ADA vs JAVA sockets

ADA vs JAVA sockets

[Riccardo]

Hi!
I'm trying to put together two applications written respectively in ADA and
in JAVA.

Each one has its own socket mechanism (in ADA I use G N A T . S O C K E T S
ver. 1.27 and in JAVA the standard sockets: JAVA.net).

Using UDP protocol on a direct connection (no other machines in between)
when I have big quantities of data it appends that some data get lost.

Introducing some delays (in both directions: either receiving in ADA or
JAVA) the problem seems to be solved.


Is there someone that found the same difficulty?

Can I say thet JAVA brings such kind of problems?
(the same program in ADA works fine with an application written in C++)

Thanks!

Riccardo

Re: ADA vs JAVA sockets

[Duncan Sands]

GNAT Sockets in 3.15p is full of bugs.

Duncan.

Re: ADA vs JAVA sockets

[Jano]

Duncan Sands dice...
> GNAT Sockets in 3.15p is full of bugs.

While it's true that it has some bugs, I think the problem comes from 
the use of UDP, which doesn't guarantee delivery.

I.e, if you send too fast you're causing the drop of packets. Over a 
non-local connection that would be more noticeable.

The solution is probably not to insert delays since the situation will 
depend on the machine/line congestion, but to implement some control of 
received data or switch to TCP.

Re: ADA vs JAVA sockets

[Pascal Obry]

Duncan Sands <baldrick@free.fr> writes:

> GNAT Sockets in 3.15p is full of bugs.

AWS works just fine with 3.15p, so saying that GNAT Sockets in 3.15p is
full of bugs is certainly pushing a bit!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA vs JAVA sockets

[Duncan Sands]

On Wednesday 07 January 2004 20:44, Pascal Obry wrote:
> Duncan Sands <baldrick@free.fr> writes:
> > GNAT Sockets in 3.15p is full of bugs.
>
> AWS works just fine with 3.15p, so saying that GNAT Sockets in 3.15p is
> full of bugs is certainly pushing a bit!

OK, Check_Selector is full of bugs (this is fixed in gcc CVS).  Also, stream
'Read and 'Write don't work well with non-blocking sockets: they try to
read (write) in a busy loop, consuming all CPU.  I didn't try most of the
other routines, perhaps they are perfect and I was unlucky to try the
only routines with problems.

Duncan.

PS:

(1) On line 367 of g-socket.adb, this

      Len := C.int'Max (Max (RSet) + 1, Len);

should be

      Len := C.int'Max (Max (WSet) + 1, Len);

(2) Check_Selector does not work for sockets with fd > 31.
Since normal files also take up fd's, you don't need to have
32 open sockets to see this.  This requires major changes to
fix, and is fixed in gcc CVS.

Gnat 3.15p bugs (was: ADA vs JAVA sockets)

[Jano]

Duncan Sands dice...
> On Wednesday 07 January 2004 20:44, Pascal Obry wrote:
> > Duncan Sands <baldrick@free.fr> writes:
> > > GNAT Sockets in 3.15p is full of bugs.
> >
> > AWS works just fine with 3.15p, so saying that GNAT Sockets in 3.15p is
> > full of bugs is certainly pushing a bit!
> 
> OK, Check_Selector is full of bugs (this is fixed in gcc CVS).  

If I had knew of this some months ago... by then I rediscovered this bug 
myself the hard way.

BTW, is somewhere a knowledge base or something about bugs in 3.15p? In 
a middle sized hobby project I've stumbled across these:

* The unreliable delays in NT
* The Check_selector bug

These are bad because can go unnoticed for quite time, and the first one 
was specially hard to track down. Sad enough, once I figured what was 
happening (by asking here, BTW, after a lot of tests), it was made 
evident that it was not a bug unheard-of.

About errors during compilation, I've had gnat crashing several times 
when compiling generics with protected types, but I couldn't extract the 
exact reasons for this. Just moved some declarations around and it 
worked.  

To have foreknowledge of these problems is obviously very interesting as 
it can save many, many time. 

Re: Gnat 3.15p bugs (was: ADA vs JAVA sockets)

[Duncan Sands]

> BTW, is somewhere a knowledge base or something about bugs in 3.15p? In
> a middle sized hobby project I've stumbled across these:
>
> * The unreliable delays in NT
> * The Check_selector bug
>
> These are bad because can go unnoticed for quite time, and the first one
> was specially hard to track down. Sad enough, once I figured what was
> happening (by asking here, BTW, after a lot of tests), it was made
> evident that it was not a bug unheard-of.
>
> About errors during compilation, I've had gnat crashing several times
> when compiling generics with protected types, but I couldn't extract the
> exact reasons for this. Just moved some declarations around and it
> worked.
>
> To have foreknowledge of these problems is obviously very interesting as
> it can save many, many time.

Try getting gcc from CVS (gcc.gnu.org) and compiling GNAT.  Many, many
bugs have been fixed.  All the bugs I know of are fixed in there.  Usually
when I report a bug to ACT, they fix it in a few days time, and the fix
turns up in CVS shortly afterwards.  The ACT people also seem to be
watching the gcc bugzilla, so you can also report bugs there.  Having
a version in bugs are fixed is better than having a list of bugs IMHO.

All the best,

Duncan.

Re: Gnat 3.15p bugs (was: ADA vs JAVA sockets)

[Jano]

Duncan Sands dice...

> Having
> a version in bugs are fixed is better than having a list of bugs IMHO.

That is true to a point. If I distribute my program open source I prefer 
to point people to Gnat 3.15p which is easily available for many 
platforms than suggesting getting the last CVS and recompile.

Perhaps the CVS commits contain annotations on fixed bugs?

Re: Gnat 3.15p bugs (was: ADA vs JAVA sockets)

[tmoran]

>Having a version in bugs are fixed is better than having a list of bugs IMHO.
  But having a list of bugs is better than a version where you get to
repeat other's painful steps finding bugs.  The Subject mentions Gnat
3.15p, which, as the unsupported "public" version, does not get bug fixes
until a new release, which is typically a year or so behind the
"supported" version.

Re: Gnat 3.15p bugs (was: ADA vs JAVA sockets)

[Duncan Sands]

>   But having a list of bugs is better than a version where you get to
> repeat other's painful steps finding bugs.  The Subject mentions Gnat
> 3.15p, which, as the unsupported "public" version, does not get bug fixes
> until a new release, which is typically a year or so behind the
> "supported" version.

Arnaud Charlet is actively moving things into the gcc tree, so hopefully
there will not be such a big time lag in the future.  It looks like gcc-3.4
will be a big leap forwards.

All the best,

Duncan.

PS: There is nothing stopping you from sending in a bug report (or,
better yet, a fix) via gcc bugzilla.  This at least documents the existence
of the bug.

Re: ADA vs JAVA sockets

[Stephen Leake]

"Riccardo" <kk@kk.com> writes:

> Each one has its own socket mechanism (in ADA I use G N A T . S O C K E T S
> ver. 1.27 and in JAVA the standard sockets: JAVA.net).
> 
> Using UDP protocol on a direct connection (no other machines in between)
> when I have big quantities of data it appends that some data get lost.
> 
> Introducing some delays (in both directions: either receiving in ADA or
> JAVA) the problem seems to be solved.

Ah. So the two applications talk to each other.

> Can I say thet JAVA brings such kind of problems?
> (the same program in ADA works fine with an application written in C++)

That would certainly indicate that Java.net is at fault!

What operating systems are you on?

Try having Ada talk to Ada, and Java to Java; that will help locate
the bug.

-- 
-- Stephe

Re: ADA vs JAVA sockets

[Steve]

RICCARDO,
  I think you will find that this is neither an Ada nor a Java problem, but
rather a characteristic of UDP.  UDP does not guarantee delivery.  If
dropping packets is a significant issue you either need to add your own
layer of logic to retransmit packets as needed, or use TCP or some other
protocol that guarantees delivery.

Steve
(The Duck)

"Riccardo" <kk@kk.com> wrote in message
news:btggi3$evu$1@e3k.asi.ansaldo.it...
> Hi!
> I'm trying to put together two applications written respectively in ADA
and
> in JAVA.
>
> Each one has its own socket mechanism (in ADA I use G N A T . S O C K E T
S
> ver. 1.27 and in JAVA the standard sockets: JAVA.net).
>
> Using UDP protocol on a direct connection (no other machines in between)
> when I have big quantities of data it appends that some data get lost.
>
> Introducing some delays (in both directions: either receiving in ADA or
> JAVA) the problem seems to be solved.
>
>
> Is there someone that found the same difficulty?
>
> Can I say thet JAVA brings such kind of problems?
> (the same program in ADA works fine with an application written in C++)
>
> Thanks!
>
> Riccardo
>
>

Re: ADA vs JAVA sockets

[Frode Tennebø]

On Wednesday 07 January 2004 09:39 Riccardo wrote:

> Can I say thet JAVA brings such kind of problems?
> (the same program in ADA works fine with an application written in
> C++)

As severel has said before, UDP does not guarantee delivery. My GUESS
is that the Ada end writes to the socket faster than the Java end can
consume it resulting in the OS' UDP buffer going full resulting in
packet loss.

 -Frode
-- 
^ Frode Tenneb� | email: frode@tennebo.com | Frode@IRC ^
|  with Standard.Disclaimer; use Standard.Disclaimer;  |

Re: ADA vs JAVA sockets

[David Marceau]

Frode Tenneb� wrote:
> 
> On Wednesday 07 January 2004 09:39 Riccardo wrote:
> 
> > Can I say thet JAVA brings such kind of problems?
> > (the same program in ADA works fine with an application written in
> > C++)
It was just luck that you seemed to have no problem.
UDP packets are not guaranteed to be delivered.

If using UDP packets, essentially you could assign some kind of ticket number to
every UDP packet and and then ensure at the receiving end you got all the
tickets.  There is the possibility that the order of reception is not as
expected either and you have to sort/assemble them in the correct order at the
receiving end.  There is also the possibility that you need to request a
specific packet with a specific ticket number to be resent.  As you can see it
gets tricky and that's why TCP exists because that's the kind of stuff it does
for you along with other stuff :)

> 
> As severel has said before, UDP does not guarantee delivery. My GUESS
> is that the Ada end writes to the socket faster than the Java end can
> consume it resulting in the OS' UDP buffer going full resulting in
> packet loss.
This is possible but please remember the java.net api is written as JNI/C code
shipped in .so's/.dlls so it should be relatively fast anyways.  Check the jdk
sources if you don't believe me.  What slows down the process in the JVM byte
code interpretation some where before and after the calls are made to java.net.

That said, I would suggest you use TCP sockets and not UDP sockets if you want
to have the packets delivered reliably.  

If you  would permit me to ask exactly what kind of application are you
writing?  

Cheers.

More details on:--- ADA vs JAVA sockets---

[Riccardo]

OK,
The possibility of loss due to UDP (I believe) is not the case (moreover we
had many other applications made only in C (C++) and ADA working correctely
for the same purpose..):

        --    the connection is exactely point to point and so (!?!?!?) no
packages should be lost                             in different directions.


The idea that I had about, is that maybe the OS queue for UDP is too small
for the quantities of data we are sending and receiving.
It is possible to set it by g-sockets or in another way????

The fact that the problems come always at the same point of the execution
(once when ADA program sends and once when JAVA program does it) should
suggest something different!??!?!?!?!

One try was to make an ADA to ADA  and JAVA to JAVA communication only, and
the programs seems, in this case, to work fine.

g-socket is really full of bug!? What Sould I use instead?

Thanks to everybody,

Riccardo




"Riccardo" <kk@kk.com> ha scritto nel messaggio
news:btggi3$evu$1@e3k.asi.ansaldo.it...
> Hi!
> I'm trying to put together two applications written respectively in ADA
and
> in JAVA.
>
> Each one has its own socket mechanism (in ADA I use G N A T . S O C K E T
S
> ver. 1.27 and in JAVA the standard sockets: JAVA.net).
>
> Using UDP protocol on a direct connection (no other machines in between)
> when I have big quantities of data it appends that some data get lost.
>
> Introducing some delays (in both directions: either receiving in ADA or
> JAVA) the problem seems to be solved.
>
>
> Is there someone that found the same difficulty?
>
> Can I say thet JAVA brings such kind of problems?
> (the same program in ADA works fine with an application written in C++)
>
> Thanks!
>
> Riccardo
>
>

Re: More details on:--- ADA vs JAVA sockets---

[tmoran]

>The possibility of loss due to UDP (I believe) is not the case ...
  An easy test would be to insert delays to artificially slow down the
transmitting side.

Re: More details on:--- ADA vs JAVA sockets---

[Riccardo]

<tmoran@acm.org> ha scritto nel messaggio
news:qUiLb.782498$Tr4.2238587@attbi_s03...
> >The possibility of loss due to UDP (I believe) is not the case ...
>   An easy test would be to insert delays to artificially slow down the
> transmitting side.

Yes, I tried it and depending on what I do in the receiving phase, some
times I miss messages:

-- when I try to print them directly on the screen
-- when I redirect the output on a file
(both operations time consuming that really delay the receiver operations)
Also in those cases, introducing delays, the problem seems to be solved..

May I set (as in UNIX SYSTEM V) , although I use SUN SOLARIS 5.8-SPARK, the
OS message queue lenght and the message size (in bytes) for the socket
communications?

The introduction of a sincronization mechanism made by a buffer queue
doesn't help in any way.

Re: More details on:--- ADA vs JAVA sockets---

[Ole-Hjalmar Kristensen]

>>>>> "R" == Riccardo  <kk@kk.com> writes:

    R> <tmoran@acm.org> ha scritto nel messaggio
    R> news:qUiLb.782498$Tr4.2238587@attbi_s03...
    >> >The possibility of loss due to UDP (I believe) is not the case ...
    >> An easy test would be to insert delays to artificially slow down the
    >> transmitting side.

    R> Yes, I tried it and depending on what I do in the receiving phase, some
    R> times I miss messages:

    R> -- when I try to print them directly on the screen
    R> -- when I redirect the output on a file
    R> (both operations time consuming that really delay the receiver operations)
    R> Also in those cases, introducing delays, the problem seems to be solved..

    R> May I set (as in UNIX SYSTEM V) , although I use SUN SOLARIS 5.8-SPARK, the
    R> OS message queue lenght and the message size (in bytes) for the socket
    R> communications?

No. UDP messages may be lost no matter what you do, that's the nature
of the beast. If you want 'reliable' communication, use TCP with your
sockets, or implement a retransmission scheme yourself.

pragma(RANT MODE ON)

(Reliable communication protocols do not really exist, all you get is
a guarantee that if the message is not delivered, you will get a
notice, so if you want application-level reliability, you, have to be
prepared to retry in some way. Going to a transactional message system
does help a little, but then transactions may fail, so you have to
retry here as well...)

pragma(RANT MODE OFF)

    R> The introduction of a sincronization mechanism made by a buffer queue
    R> doesn't help in any way.



-- 
This page intentionally left blank

thanks

[Riccardo]

Thanks to everybody!
I'll consider all these considerations in arranging a new solution.

Riccardo

Re: thanks

[Robert Spooner]

Riccardo,

If you want to use TCP/IP but make it look like a (reliable) UDP/IP 
protocol at a higher level, one way to do it is to layer a record 
structure on top of TCP that sends size in bytes as a fixed length 
preamble of every message. You read the size, and then loop until you 
have read the correct number of bytes for the entire message.

Another way to do it is by using streams.

Regards,
Bob

Riccardo wrote:
> Thanks to everybody!
> I'll consider all these considerations in arranging a new solution.
> 
> Riccardo
> 
> 
> 
> 

-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu