On 2 Mar 2005, [EMAIL PROTECTED] wrote:

>> This related to NAT forwarding that I have turned on on Linux
>> 2.6.10.  The connection tracking only has a limited number of
>> entries and as an Ultra-node, GTKG opens so many connections that
>> there are no connection left.

> That might be much more of a problem for "hardware routers" which
> have a very limited amount of RAM usually. I'd think for your Linux
> box there should be a way to increase the amount of memory reserved
> for NAT mappings - that is unless it's already too low on memory.

>> It seems that running GTKG on a box with ip forwarding would not be
>> a good idea.  Probably the same for a web server, etc.

> Normally, you'd set up a static NAT route so that you don't need to
> track each single connection.

I am not really sure what a static NAT route is.  I looked around
trying to find it.  I have updated iptables and I think I need to take
a closer look at how to create the NAT chains.  I guess that there is
something like a "static NAT route" somewhere in the iptables man
pages.

The problem is that NAT must track host sockets (box performing NAT)
as it could re-assign a valid socket for the host to a translated
device.  I guess that certian blocks of ports could be set aside for
NAT and others for GTKG, etc on the NATing host.  That makes sense and
my guess would be that is what a "static NAT route" is?

For the interm, there is a rather handy proc entry,

 # echo "200000" > /proc/sys/net/ipv4/ip_conntrack_max

This was set to 8192 by default on my Mandrake system.  It is probably
a default.

I still get a lot of mallopt() core dumps.  I recompiled with "plain"
options and the problem is still occurring with source from today.
The only option I didn't change was the stack smasher; but at one
point I had accidentally turned this option off [and still had a
similar trace].  The stack never ends at gtk_main() [or whatever it
is], so I don't even know if mallopt/malloc is a culprit... but I have
had easily 20 cores like this.

I attempted to run splint on the code.  It works for the most part.
The only difficulty is to deal with GCC var_arg macros.  I was
ifdef'ing this, but splint would still puke sooner or later.

Unfortunately, I don't have time to pour over the results.  I have to
go to FrankFurt for the next 4 weeks.  Somebody else will probably
have squashed that bug by then.

btw, why no SO_LINGER options?  Couldn't a meany perform a DOS attack
on a GTKG node?  I guess we are trying to be nice to other nodes?

fwiw,
Bill Pringlemeir.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Gtk-gnutella-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

Reply via email to