On 11/03/02 21:33 +0530, Shridhar Daithankar wrote: > Umm.. OK. Let's say all dial-up connections on private space. One server > handles 128 incoming calls. That server has public IP. So it can effectively > route to any of machines that are dialing in that machine. Repeat the scheme > for every server that handles incoming dial-ups. > > But then, how do I connect to your PC from another ISP? Did you forget > > that? NATing servers is a bad idea. NATing clients is acceptable, but > > not good either. and I sure as hell dislike passive ftp in my servers:) > > I guess in scheme above it's possible to connect from other ISP. Ummm, right. I have the ip address 10.1.1.100. Please connect to my webserver from a second ISP which gives you 192.168.1.100. Note that the Net was designed for peer to peer stuff. Client server is one way of doing it, but you are breaking peer to peer. Effectively converting the Net to a Web only television ground.
> > P2P : which is the client and which is the server? I want to run a web > > server on my dialup? Can';t do it with NAT. > > Protocols like H323 which embed the client IP into the packet data (not > > just the headers) break due to NAT. > > I guess that's unsurpassable unless there is H323 proxy. > > I'm sorry if I am sounding increasingly stupid but all I want to see is if > public IPs are used in a bit better/efficient manner. NAT or not I > don't care. Hmmm, then we should start by taking away a lot of class A blocks and redistributing them via CIDR. IBM doesn't need 9/8, MIT doesn't need 18/8+ a few class B blocks. Stanford did the right thing, now all the others should follow too. Though, we should be moving to ipv6, or further. Devdas Bhagat _______________________________________________ linux-india-help mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/linux-india-help
