> 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