I like this as well. On Feb 15, 2011 6:11 PM, "kitepilot@kitepilot.com" wrote: >> 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