Michael Yeung <[EMAIL PROTECTED]> wrote:
>
>I noticed IP aliases restrict the alias IP address to be in the same
>subnet/network as the primary IP address. Is that a true restriction?
No. You configure aliases exactly as you would the primary address on
an interface without restriction, except th
Brian Somers <[EMAIL PROTECTED]> wrote:
>
>Hmm, the last time i looked at this, I believe the whole thing was
>dealt with by not increasing the file descriptor reference count
>when it was put in the message header. If process A closed the
>descriptor before process B actually recvmsg()d it, i
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
>I guess the gc has to stay.
>
>dammit. :)
>
>My apologies for wasting everyone's time here.
``One day a student came to Moon and said: "I understand how to make a
better garbage collector. We must keep a reference count of the
pointers to each cons."
Matt Dillon <[EMAIL PROTECTED]> wrote:
>
>No waste at all, Alfred, the file descriptor passing code had been
>broken for over 10 years precisely because of its complexity. Rewriting
>the GC to be more efficient essentially requires using deep graph theory
>to locate isolated loops
Tony Finch <[EMAIL PROTECTED]> wrote:
>
>Instead of the existing breadth-first search of the whole file table
>at the start of unp_gc, it should first clear the mark on each
>descriptor on the in-flight list, then do a depth-first search of all
>the descriptors reachable
Tony Finch <[EMAIL PROTECTED]> wrote:
>
>R. D. Lins: "Cyclic Reference Counting with Local Mark-Scan";
>Information Processing Letters 44(4):215-220, 1992; University of Kent
>at Canterbury Computing Laboratory Technical Report 75, July 1990.
http://citeseer.nj.nec
Terry Lambert <[EMAIL PROTECTED]> wrote:
>
>SVR4 and Solaris avoid the problem entirely by ensuring that
>each reference to a vnode pointer counts as an "open", and
>the vnode can not be discarded until a 1->0 reference count
>change (grep for VHOLD/VRELE/VREF in the Solaris headers).
FreeBSD doe
Matt Dillon <[EMAIL PROTECTED]> wrote:
>
>We are *not* going create a separate ref count field just to track
>socket queue references, because this breaks the file descriptor passing
>semantics...
There is an f_msgcount field already but isn't used for the sort of
half-baked hack at t
Jesper Skriver <[EMAIL PROTECTED]> wrote:
>
>- If the sysctl net.inet.tcp.icmp_admin_prohib_like_rst == 1 (default)
> it enables the below.
I think those are the wrong semantics: ICMP administratively
prohibited should work like host and network unreachable, i.e.
existing connections should not
Kris Kennaway <[EMAIL PROTECTED]> wrote:
>On Thu, Feb 01, 2001 at 01:31:39PM +0800, bsddiy wrote:
>
>> I don't want to bring flame war, but the following Linus' words may
>> be right:
>
>Did you have a point to make here? If so, I missed it.
I've been discussing this with a few people recently (f
Justin Booth <[EMAIL PROTECTED]> wrote:
>
>The following code has a problem with it. After 16000 or so connections
>the my tcp connections run out of buffer space, which does not allow me to
>make any new TCP connections and the system locks up. an netstat -an
>revieles that there are about 10
Garrett Wollman <[EMAIL PROTECTED]> wrote:
>Tony Finch <[EMAIL PROTECTED]> wrote:
>>
>> For this reason turning off TCP_CORK pushes out queued data, but
>> this isn't the case for TCP_NOPUSH.
>
>This is a long-standing bug. You are welcome to fix it.
David Xu <[EMAIL PROTECTED]> wrote:
>
>but as I know, it seems TCP_NOPUSH is mainly used for TTCP, right?
That's what it was designed for.
>the idea behind TCP_CORK is it buffers any small data segment user
>program sending until these segments full fills a max TCP packet,
>then the packet is se
Tony Finch <[EMAIL PROTECTED]> wrote:
>Garrett Wollman <[EMAIL PROTECTED]> wrote:
>>Tony Finch <[EMAIL PROTECTED]> wrote:
>>>
>>> For this reason turning off TCP_CORK pushes out queued data, but
>>> this isn't the case for TCP_NOPUSH.
&
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
>I was going to say the same thing, but what about the header
>before a cgi response? Doesn't the webserver need to spit out
>a couple of short lines before exec'ing the CGI?
No. The first line of the HTTP response ("HTTP/1.1 200 OK" or
whatever) dep
Garrett Wollman <[EMAIL PROTECTED]> wrote:
>
>I think the common-sense interpretation when one speaks of the
>``maximum length'' of some string is that it is the maximum value
>strlen() might return, and doesn't include metainformation.
However it slightly uglifies idiomatic coding of things like
Tommi Harkonen <[EMAIL PROTECTED]> wrote:
>Garrett Wollman wrote:
>>
>> Clearly, your packets are not getting anywhere.
>
> Traceroute & ping works fine from the box and everything to the box (still)
>works and I have checked, double checked and triple checked all settings
This sounds like a p
Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
>Considering JDP's comment it's not useful at all in an Internet
>environment. So practically it doesn't matter if it's gone.
I think it may be useful in the back end of a server cluster.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
SOLE
Mike Silbersack <[EMAIL PROTECTED]> wrote:
>
>I can see how these source quench messages would cause problems if a DoS
>is being routed through a FreeBSD router, and I think that your patch
>makes sense. Are there any objections to me committing this in a few
>days?
Doesn't FreeBSD rate-limit ICM
There seems to be a slight lacuna in the signal documentation:
--- src/lib/libc/gen/signal.3 19 Dec 2002 09:40:21 - 1.32
+++ src/lib/libc/gen/signal.3 10 Jan 2003 16:03:16 -
@@ -187,7 +187,9 @@
and during a
.Xr ioctl 2
or
-.Xr wait 2 .
+.Xr wait 2
+or any other system call whos
Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
>Linux never will. They consider TTCP broken by design. [...]
>The problem is that TTCP will never make it mainstream or even
>little side stream. FreeBSD is the only BSD implementing it.
The reason for its lack of popularity is that it has significan
Julian Elischer <[EMAIL PROTECTED]> wrote:
>
> I have noticed an increasing number of machines on the net
>are terminating their session (usually the server, but not always)
>with a RESET packet instead of a FIN packet.
>
>I don't know what kind of machines this is but next time I see it I
>guess
Anders Lowinger <[EMAIL PROTECTED]> wrote:
>Luigi Rizzo wrote:
>>
>> i was wondering if anyone knows what kind of support we have
>> in FreeBSD networking code, for non contiguous netmasks.
>> While it is trivial to support them for interface addresses,
>> managing them in the routing table is prob
Julian Elischer <[EMAIL PROTECTED]> wrote:
>
>I use RR all the time.
>it allows you to record the reverse path, (up to the size limitation).
When I worked at an ISP that used BSD routers everywhere on which I had
root, I wrote an evil little script for that purpose...
http://dotat.at/prog/scripts
24 matches
Mail list logo
