Re: Proper IP address for PC to Iseries connection -- MIDRANGE-L

Your design is flawed - an IP address does not represent a single user,
nor does it represent a single user.

I'm aware that there are issues. I'm trying to narrow them down so that
various users can use the option that suits them best.

STRPCO seems to work quite well but has a miserably short command string
length (that I can live with if need be, for them). It also opens a PC
command window that is annoying to see. The ultimate PC java program also
works much better if it calls the ultimate class from within itself instead
of being call from the command line by STRPCO.

NAT seems to work as long as NAT travesal (sp) is disabled. (Which seems to
help VPN connections anyway, but I don't recall why at the moment.)

The other failure points may have a hack that some user could use, though a
hack is a hack [yuk]

The concatenation idea would yield a unique id but I need to have a host
application know it so it can be used as a key for the data queue entry.

Since the host seems to retrieve the proper IP address perhaps I can have
the PC java app call a host app to send back the IP address the host sees.
The host response could be placed on a 2nd data queue using the concatenated
id. Seems pretty silly to ask what ones name is, though as I get older I can
see where that could become a reality. [smile]

Steve

Your application will break if the client is behind NAT.
Your application will break if it is running on a Terminal Server.
Your application might break if there are short DHCP lease times.

You'll need another design. If your client is Windows, I would recommend
a concatenation of the machine SID, user SID and the Session ID - this
WILL be unique in every scenario.

If you're looking for a more universal solution, it get's more
difficult. You can use the hostname and the username, but this might not
always work.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On
Behalf Of Steve Moland
Sent: Monday, June 25, 2007 8:16 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Proper IP address for PC to Iseries connection

Just when I thought I was done.

I've a java application on a PC which waits for and processes keyed data

queues entries placed in the queue by an AS400 application. The "key"
being
the IP address of the PC running a CA session as retrieved by RPG using
the
API QDCRDEVD.

Until today I worked on this off site thru a Sonicwall VPN and the java
app
retrieved the same IP address as the RPG app.

While connected locally, it turns out that the IP address the java app
retrieves using "InetAddress.getLocalHost" does not retrieve the IP
address
on my local nic card. Instead it is retrieving the address of the my VPN

driver that is installed on my PC. The annoying part is that the RPG app

does retrieved the IP address of the local nic card.

My observation is that the VPN IP address is the culprit but only
because it
is the 3rd IP address available as viewed by running IPCONFIG /ALL in a
command window. The 2nd IP address is my wirecard which is shut off. I
think
my observation is correct because if I physically disable the VPN driver

(and hence the virtually IP address assigned), then the java app returns
the
local nic card IP address.

I think "InetAddress.getLocalHost" is reading them all and returning the

last one encountered

I need to roll this app out to hundreds of users on multiple AS400 boxes
and
I don't want to have to have anyone manually assign some unique
identifying
code for each PC session which in turn would have to be available (and
known) to the RPG application. Nor do I want a PC user to have to shut
off
any physical or virtual nic addresses.

Any suggestions for an approach. This worked so seamlessly until this
AM.

What I thought of doing (because I found java code to do it) is to
retrieve
ALL the IP addresses on a PC and then try each of them as the key on the

read of the keyed data queue.
--

Steve Moland
Access Paths Inc
12 Parmenter Rd Unit C4
Londonderry NH 03053
603 845-0190 Ext 2
steve@xxxxxxxxxxx

--
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.