|> From: Jim Shankland [mailto:jas@parker.net] |> Sent: Friday, September 07, 2001 12:35 PM |> |> Roeland Meyer <rmeyer@mhsc.com> writes: |> |> > You've just described a NAT proxy daemon. I've spent years |> trying to write |> > one. If you are that good, send code. Or better yet, send it to |> > www.sourceforge.org. The fundimental reason that you can't |> write one is that |> > it requires a whole other protocol that 1) deosn't exist, 2)Isn't |> > implemented, 3)Violates more than one of Dykstra's laws. |> |> Don't mean to nitpick, but I was describing no such thing. I was |> suggesting the development of a protocol. Saying that can't be done |> because the protocol "1) deosn't exist, 2)Isn't implemented" seems |> a little circular :-). Don't know which of Dijkstra's laws |> that might |> violate, either (except maybe "Don't misspell my name" :-)). I'm also dutch and should know better. However, neither can I type, as the quoted portion clearly shows. .. cna't spell, can't type, I must write code <g>. lint will save me. I'm also too terse for my own good, sometimes. Item 2 is looking forward to deployment. Adoption will be supremely difficult and unless universally adopted, it won't fly. It's a flash cut-over scenario with disparate implementors. Success is estimated at around 0.001%, in such cases. The law I am thinking of is the one where the application can't tell where the failure is until it fails. It is fundimentally unpredictable. |> The argument, roughly, is that there is a small set of operations |> (identifying an <ipaddr:port> tuple in a network-portable way, and |> dynamically allocating a new port to an application, are two |> that come |> to my mind) that make NAT and firewalls difficult for games, |> streaming |> audio/video, etc.; and that providing a standard protocol for these |> operations would make building such applications, and having them |> interoperate well with NATs and firewalls, much easier. |> |> I'm not convinced this argument is correct, though it passes the |> first-tier plausibility test in my mind. I just thought I'd float |> the trial balloon. The problem is in how to deal with the legacy. Also, most FW builders don't want to give out any clue to a potential attacker, so they silently discard the packets. In this case, how is a feedback mechanism supposed to work?