Re: Odd sockets problem?

Thanks.

There is no proxy being used here, it's all internal.  I
would assume (maybe wrongly) that their IE apps don't have
a proxy set up... I guess NAT is more of the norm these
days.  But I could ask.

Brad

On Mon, 29 Nov 2004 17:43:25 -0000
 "Ian Patterson" <ian@xxxxxxxxxxxxxxxxxxxx> wrote:
> Not sure if this helps, but when we were testing a
> Windows based IP sockets
> program connecting to the 'outside', the standard Windows
> API's that handle
> the routing (WinInet) take the defaults from IE.
> So if a proxy setting existed in IE (say to use 8080)
> this was also adopted
> by our Windows program that wrote directly to sockets
> using WinInet as the
> comms API.
> 
> 
> Regards
> 
> Ian Patterson
> 
> ian@xxxxxxxxxxxxxxxxx <mailto:ian@xxxxxxxxxxxxxxxxx>
> 
> Grange IT Limited
> tel 01947 880458
> www.grangesystems.com
> 
> 
> 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Brad
> Stone
> Sent: 29 November 2004 17:29
> To: Midrange Systems Technical Discussion
> Subject: Re: Odd sockets problem?
> 
> 
> That is my thought, but I'm not sure how to tell him how
> to
> look for those types of issues.
> 
> Are there ways to do trace routes to particular ports?
>  And
> if I have him do it from windows (dos), would it be the
> same as from his browser?  Or would IE have anything set
> up
> with it that would cause this sort of problem?
> 
> On Mon, 29 Nov 2004 12:15:18 -0500
>  Jeff Silberberg <jsilberberg@xxxxxxxxxxxxxx> wrote:
> >
> > Brad,
> >
> >         Could you have a Firewall / NAT server doing
> some
> > port mapping on
> > either end ? Trace Routes..
> >
> >         His workstation with a browser, may be being
> > handled different
> > than the IP address in the AS/iSeries box. Depending on
> > the rules along the way..
> >
> >         JMS...
> >
> > At 12:05 PM 11/29/2004, you wrote:
> > >Ok, here's the scoop.
> > >
> > >I have a customer using my GETURI utility to work with
> > web
> > >services.  He is testing on some IntrAnet services.
> > >
> > >He says he has 2 enviroments set up.  One on port 8080
> > >which is a test environment, and one on ports 8081 and
> > 80
> > >which are production.
> > >
> > >>From a web browser, if he specifies port 8080 or
> 8081,
> > he
> > >gets the right server.
> > >
> > >But from GETURI, he says if he uses port 8080 or port
> > 8081,
> > >he always gets a response back from the 8081 (prod)
> box.
> > >
> > >I had him place a static document on each server.  The
> > test
> > >one said TEST, the Prod one said PROD.  He tested with
> > the
> > >browser, and got the appropriate document.
> > >
> > >He then tested with GETURI, and always got the PROD
> > >document no matter if he specified 8080 or 8081 for
> the
> > >port number.
> > >
> > >I've tripled checked the source, debugged, and
> couldn't
> > >find any way that the port could be getting changed.
> > >
> > >I also had him test on my web site on port 80 and port
> > 8080
> > >which should reveal different results.  Port 80 worked
> > >fine, port 8080 resulted in no connection, most likely
> > >because their firewall is blocking that port (which
> then
> > >proves that the port GETURI was using works fine).  He
> > got
> > >the same results on his browser.
> > >
> > >I'm really pulling my hair out on this one.  I've got
> > >hundreds of users using this without this problem, so
> > I'm
> > >leaning towards some sort of odd web server config
> (they
> > >are running all websphere servers) or networking
> > problem.
> > > But I'm running out of ideas on where to look.
> > >
> > >What would cause his browser and GETURI (which uses
> > sockets
> > >APIS) to act differently?    Thanks for any ideas...
>  I
> > >know there are a lot out there with more netorking
> know
> > how
> > >than me that could offer possible ideas.
> >
> > Jeffrey Silberberg
> > CompuDesigns, Inc.
> > Atlanta, GA. 30350
> >
> > As soon as I know the answers
> > They change the questions !
> > --
> > 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.
> >
> 
> Bradley V. Stone
> BVS.Tools
> www.bvstools.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.
> 
> 
> 
> --
> 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.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com