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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,83a56cb8370ebd04 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-09 00:50:01 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.vmunix.org!feed.news.tiscali.de!news.belwue.de!news.uni-stuttgart.de!carbon.eu.sun.com!new-usenet.uk.sun.com!not-for-mail From: Ole-Hjalmar Kristensen Newsgroups: comp.lang.ada Subject: Re: More details on:--- ADA vs JAVA sockets--- Date: 09 Jan 2004 09:45:21 +0100 Organization: Sun Microsystems Message-ID: References: NNTP-Posting-Host: khepri06.norway.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: new-usenet.uk.sun.com 1073637921 27320 129.159.112.195 (9 Jan 2004 08:45:21 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 9 Jan 2004 08:45:21 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:4252 Date: 2004-01-09T08:45:21+00:00 List-Id: >>>>> "R" == Riccardo writes: R> 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