> Example 1: Use NX Free edition to get a desktop on another computer, and
> then run your browser on that.
Man, why so cumbersome...
ssh -fCXY myuser@remotebox firefox
will do...
ET
Kevin Fries writes:
> On 02/15/2011 11:51 AM, Joseph Sinclair wrote:
>> I would assume that he's talking about broad testing within a local
>> network, rather than testing against localhost directly.
>> I often do this because I can insert firewalls, routers, etc... as/where
>> desired to emulate probable scenarios. It's particularly helpful to
>> emulate 4in6 or 6in4 connections when using external providers that do
>> not provide sufficient IPv6 support.
>>
>> It's just easier to create a hostfile entry on the test client(s) than to
>> create or modify public DNS (sometimes that's not even possible). This
>> is particularly true when the service you're testing is already live and
>> you need to black-box test a component of an interconnected SOA system.
> Yes, I understand that. My point is to question if this is wise at all.
> I have seen far too many times where a computer sends traffic out to its
> public address, and still does not respond the same way it does in
> production. The reason is one NIC. You are routing from yourself to
> yourself, and it will get turned around at the NIC. I have worked R&D for
> the past 4 1/2 years, and trust me, this happens far more than most people
> think. You would be better off bouncing off another computer, that
> redirects the traffic truly from another machine.
>
> Example 1: Use NX Free edition to get a desktop on another computer, and
> then run your browser on that.
>
> Example 2: Use a *Nix machine for which you have root access to create a
> forwarded port (ssh -R 80:mypublicip:80 root@server). This makes the IP
> address on the foreign machine tunnel back to yourself, and cuts out
> optimizations at both the NIC and the switch and gives you a true
> experience as to what your clients will see.
>
> Example 3: Have a second NIC. Force traffic out through NIC-1 to the
> public IP on NIC-2. The switch and NIC have no idea that the machine
> sending and responding are one in the same. Therefore, once again, you
> can eliminate any ability of the devices to optimize.
>
> As I said in my original comment. The goal is to avoid the "It works on
> my machine" situation.
>
> I hope my comments made more sense this time.
>
> Kevin
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)