* ADA vs JAVA sockets @ 2004-01-07 8:39 Riccardo 2004-01-07 13:31 ` Duncan Sands ` (4 more replies) 0 siblings, 5 replies; 20+ messages in thread From: Riccardo @ 2004-01-07 8:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ADA vs JAVA sockets 2004-01-07 8:39 ADA vs JAVA sockets Riccardo @ 2004-01-07 13:31 ` Duncan Sands 2004-01-07 16:28 ` Jano 2004-01-07 19:44 ` Pascal Obry 2004-01-07 14:24 ` ADA vs JAVA sockets Stephen Leake ` (3 subsequent siblings) 4 siblings, 2 replies; 20+ messages in thread From: Duncan Sands @ 2004-01-07 13:31 UTC (permalink / raw) To: Riccardo, comp.lang.ada GNAT Sockets in 3.15p is full of bugs. Duncan. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ADA vs JAVA sockets 2004-01-07 13:31 ` Duncan Sands @ 2004-01-07 16:28 ` Jano 2004-01-07 19:44 ` Pascal Obry 1 sibling, 0 replies; 20+ messages in thread From: Jano @ 2004-01-07 16:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ADA vs JAVA sockets 2004-01-07 13:31 ` Duncan Sands 2004-01-07 16:28 ` Jano @ 2004-01-07 19:44 ` Pascal Obry 2004-01-07 21:11 ` Duncan Sands 1 sibling, 1 reply; 20+ messages in thread From: Pascal Obry @ 2004-01-07 19:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ADA vs JAVA sockets 2004-01-07 19:44 ` Pascal Obry @ 2004-01-07 21:11 ` Duncan Sands 2004-01-08 14:31 ` Gnat 3.15p bugs (was: ADA vs JAVA sockets) Jano 0 siblings, 1 reply; 20+ messages in thread From: Duncan Sands @ 2004-01-07 21:11 UTC (permalink / raw) To: Pascal Obry, comp.lang.ada 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Gnat 3.15p bugs (was: ADA vs JAVA sockets) 2004-01-07 21:11 ` Duncan Sands @ 2004-01-08 14:31 ` Jano 2004-01-08 16:24 ` Duncan Sands 0 siblings, 1 reply; 20+ messages in thread From: Jano @ 2004-01-08 14:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Gnat 3.15p bugs (was: ADA vs JAVA sockets) 2004-01-08 14:31 ` Gnat 3.15p bugs (was: ADA vs JAVA sockets) Jano @ 2004-01-08 16:24 ` Duncan Sands 2004-01-08 19:14 ` Jano 2004-01-08 20:16 ` tmoran 0 siblings, 2 replies; 20+ messages in thread From: Duncan Sands @ 2004-01-08 16:24 UTC (permalink / raw) To: Jano, comp.lang.ada > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Gnat 3.15p bugs (was: ADA vs JAVA sockets) 2004-01-08 16:24 ` Duncan Sands @ 2004-01-08 19:14 ` Jano 2004-01-08 20:16 ` tmoran 1 sibling, 0 replies; 20+ messages in thread From: Jano @ 2004-01-08 19:14 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Gnat 3.15p bugs (was: ADA vs JAVA sockets) 2004-01-08 16:24 ` Duncan Sands 2004-01-08 19:14 ` Jano @ 2004-01-08 20:16 ` tmoran 2004-01-08 20:58 ` Duncan Sands 1 sibling, 1 reply; 20+ messages in thread From: tmoran @ 2004-01-08 20:16 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Gnat 3.15p bugs (was: ADA vs JAVA sockets) 2004-01-08 20:16 ` tmoran @ 2004-01-08 20:58 ` Duncan Sands 0 siblings, 0 replies; 20+ messages in thread From: Duncan Sands @ 2004-01-08 20:58 UTC (permalink / raw) To: tmoran, comp.lang.ada > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ADA vs JAVA sockets 2004-01-07 8:39 ADA vs JAVA sockets Riccardo 2004-01-07 13:31 ` Duncan Sands @ 2004-01-07 14:24 ` Stephen Leake 2004-01-07 15:43 ` Steve ` (2 subsequent siblings) 4 siblings, 0 replies; 20+ messages in thread From: Stephen Leake @ 2004-01-07 14:24 UTC (permalink / raw) To: comp.lang.ada "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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ADA vs JAVA sockets 2004-01-07 8:39 ADA vs JAVA sockets Riccardo 2004-01-07 13:31 ` Duncan Sands 2004-01-07 14:24 ` ADA vs JAVA sockets Stephen Leake @ 2004-01-07 15:43 ` Steve 2004-01-07 22:23 ` Frode Tennebø 2004-01-08 8:32 ` More details on:--- ADA vs JAVA sockets--- Riccardo 4 siblings, 0 replies; 20+ messages in thread From: Steve @ 2004-01-07 15:43 UTC (permalink / raw) 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 > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ADA vs JAVA sockets 2004-01-07 8:39 ADA vs JAVA sockets Riccardo ` (2 preceding siblings ...) 2004-01-07 15:43 ` Steve @ 2004-01-07 22:23 ` Frode Tennebø 2004-01-08 7:09 ` David Marceau 2004-01-08 8:32 ` More details on:--- ADA vs JAVA sockets--- Riccardo 4 siblings, 1 reply; 20+ messages in thread From: Frode Tennebø @ 2004-01-07 22:23 UTC (permalink / raw) 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; | ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ADA vs JAVA sockets 2004-01-07 22:23 ` Frode Tennebø @ 2004-01-08 7:09 ` David Marceau 0 siblings, 0 replies; 20+ messages in thread From: David Marceau @ 2004-01-08 7:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* More details on:--- ADA vs JAVA sockets--- 2004-01-07 8:39 ADA vs JAVA sockets Riccardo ` (3 preceding siblings ...) 2004-01-07 22:23 ` Frode Tennebø @ 2004-01-08 8:32 ` Riccardo 2004-01-08 20:16 ` tmoran 4 siblings, 1 reply; 20+ messages in thread From: Riccardo @ 2004-01-08 8:32 UTC (permalink / raw) 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 > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: More details on:--- ADA vs JAVA sockets--- 2004-01-08 8:32 ` More details on:--- ADA vs JAVA sockets--- Riccardo @ 2004-01-08 20:16 ` tmoran 2004-01-09 7:27 ` Riccardo 0 siblings, 1 reply; 20+ messages in thread From: tmoran @ 2004-01-08 20:16 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: More details on:--- ADA vs JAVA sockets--- 2004-01-08 20:16 ` tmoran @ 2004-01-09 7:27 ` Riccardo 2004-01-09 8:45 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 20+ messages in thread From: Riccardo @ 2004-01-09 7:27 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: More details on:--- ADA vs JAVA sockets--- 2004-01-09 7:27 ` Riccardo @ 2004-01-09 8:45 ` Ole-Hjalmar Kristensen 2004-01-09 10:27 ` thanks Riccardo 0 siblings, 1 reply; 20+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-01-09 8:45 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* thanks 2004-01-09 8:45 ` Ole-Hjalmar Kristensen @ 2004-01-09 10:27 ` Riccardo 2004-01-09 13:58 ` thanks Robert Spooner 0 siblings, 1 reply; 20+ messages in thread From: Riccardo @ 2004-01-09 10:27 UTC (permalink / raw) Thanks to everybody! I'll consider all these considerations in arranging a new solution. Riccardo ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: thanks 2004-01-09 10:27 ` thanks Riccardo @ 2004-01-09 13:58 ` Robert Spooner 0 siblings, 0 replies; 20+ messages in thread From: Robert Spooner @ 2004-01-09 13:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2004-01-09 13:58 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-07 8:39 ADA vs JAVA sockets Riccardo 2004-01-07 13:31 ` Duncan Sands 2004-01-07 16:28 ` Jano 2004-01-07 19:44 ` Pascal Obry 2004-01-07 21:11 ` Duncan Sands 2004-01-08 14:31 ` Gnat 3.15p bugs (was: ADA vs JAVA sockets) Jano 2004-01-08 16:24 ` Duncan Sands 2004-01-08 19:14 ` Jano 2004-01-08 20:16 ` tmoran 2004-01-08 20:58 ` Duncan Sands 2004-01-07 14:24 ` ADA vs JAVA sockets Stephen Leake 2004-01-07 15:43 ` Steve 2004-01-07 22:23 ` Frode Tennebø 2004-01-08 7:09 ` David Marceau 2004-01-08 8:32 ` More details on:--- ADA vs JAVA sockets--- Riccardo 2004-01-08 20:16 ` tmoran 2004-01-09 7:27 ` Riccardo 2004-01-09 8:45 ` Ole-Hjalmar Kristensen 2004-01-09 10:27 ` thanks Riccardo 2004-01-09 13:58 ` thanks Robert Spooner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox