RE: Apparent timing problem with socket communications

Along that line, if anyone has a copy of the CD for Sniffer Basic by Network
Solutions, please let me know. Mine got bashed in a kid-crash. 

John Brandt 
iStudio400.com 
(903) 523-0708 
Home of iS/ODBC - MSSQL access from iSeries and RPG. 




-----Original Message-----
From: Donald Whittaker [mailto:donald_whittaker@xxxxxxxxx]
Sent: Tuesday, November 09, 2004 12:49 PM
To: Midrange Systems Technical Discussion
Subject: Re: Apparent timing problem with socket communications


   Since no one else wants to go first...
   The part that caught my eye was the comment that
the client "fails to receive the reply sent by the
server."
   Does it "fail to receive" or does it "fail to do
anything about it"?
   Perhaps a trace might shed some light on the issue.
   I have had good luck using Ethereal
(www.ethereal.com) on my PC to determine such things,
although I am sure there are many others.
Hope that helps, or at least encourages smarter people
to jump in.

Don Whittaker
PowerTech
 
--- James H H Lampert <jamesl@xxxxxxxxxxx> wrote:

> This really did get absolutely no response last
> week, on the Java list
> (after what happened with my Unicode query before, I
> double-checked). And
> once again, I'm not at liberty to be any more
> specific than I already
> have. And I'm stumped on it, and unable to provide
> anything but a
> palliative.
> 
> Fellow programmers:
> 
> I'm afraid I can't get into specifics here, but I've
> got a weird timing
> problem with a Java client talking to an
> AS/400-native client (ILE C and
> ILE RPG) through a socket, in an established
> connection. Under easily
> duplicated conditions, the client sends a request to
> the server, then
> fails to receive the reply sent by the server. Yet
> if I put diagnostics (a
> series of printf statements in the C portion) into
> the part of the server
> that processes the request and sends the reply, or
> even if I just have the
> server wait for a fraction of a second, it works
> fine. In our own
> installation. Yet it still fails at the customer
> site.
> 
> About the only specifics I can get into here are
> that the Java client is
> reading the reply from a DataInputStream on a
> BufferedInputStream on the
> stream returned from a getInputStream() on the
> socket.
> 
> It's my understanding that the BufferedInputStream
> layer should keep
> anything from getting lost if the client isn't ready
> to listen when the
> reply comes in. And yet that appears to be what's
> somehow happening. Any
> suggestions on what could be going wrong?
> 
> (And I've already shared all the specifics I dare,
> so please don't ask for
> more.)
> 
> --
> James H. H. Lampert
> 
> 
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
>
http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 
> 



                
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.789 / Virus Database: 534 - Release Date: 11/7/04
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.789 / Virus Database: 534 - Release Date: 11/7/04