> On Thu, 21 Oct 2004 21:32:48 +0200
> [EMAIL PROTECTED](Marco Molteni) said:
> SCTP in KAME is complete, stable and fully supported.
> It is mainly developed by the SCTP RFC author, Randall Stewart.
KAME Project haven't received SCTP-related bug report so much, and I
think it's due to a
Andre Oppermann <[EMAIL PROTECTED]> writes:
> o T/TCP only available on FreeBSD. No other Operating System or TCP/IP
> stack implements it to my knowledge. Certainly no OS that is common.
AFAIK, both Linux and Windows support it, at least on the server side
(i.e. they can receive T/TCP con
[EMAIL PROTECTED] (Dag-Erling Smørgrav) writes:
> [...]
I should add: I'm not against removing T/TCP support (especially if it
helps simplify our network stack), but I don't see the point in
replacing it with some homebrew protocol that noone else supports.
DES
--
Dag-Erling Smørgrav - [EMAIL PR
Marco Molteni wrote:
>
> On Thu, 21 Oct 2004 Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
> > Bruce M Simpson wrote:
> > >
> > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
> > > > Thus after the removal of T/TCP for the reasons above I want to
> > > > provide a work-alike re
Dag-Erling Smørgrav wrote:
>
> Andre Oppermann <[EMAIL PROTECTED]> writes:
> > o T/TCP only available on FreeBSD. No other Operating System or TCP/IP
> > stack implements it to my knowledge. Certainly no OS that is common.
>
> AFAIK, both Linux and Windows support it, at least on the serv
Ronald F. Guilmette wrote this message on Wed, Oct 20, 2004 at 13:22 -0700:
> >This is because aio_ requires a kernel thread
> >to wait for you instead of your process context.. Currently we are limited
> >to only executing 4 aio_ events at once.. This can be increased, but will
> >incure a stack
John-Mark Gurney wrote this message on Fri, Oct 22, 2004 at 10:27 -0700:
> Brian Feldman did start work on making kqueue's send signals when an
> event became available, but it was put on the back burner because of a
> problem w/ locking since, that signel could also wake up the kqueue
> that deliv
In message <[EMAIL PROTECTED]>, you wrote:
>Oh, another thing is that there isn't yet a verbose signal delivery
>mechanism.. There are only two signals that are for user's use...
^defined in relevant standards
Signal numbers are typically represented as i
< said:
> Signal numbers are typically represented as ints. Is there anything in
> the kernel that prevents me from, say, calling kill(2) with a second
> argument of, say, 0xdeadbeef, in other words any old random int value
> that I might care to use?
Yes. Signals are represented, in the kernel
> A T/TCP alternative as you are describing sounds very
> similar to PR-SCTP (Partial Reliability SCTP). (Don't let the
> name fool you, please read the internet draft).
Can you sketch this in a bit more detail? I do not follow. PR-SCTP is
about being allowed to "abandon" data --- i.e., send it
The servers are busier today and error 49 is comming up frequently now.
Here are some results of what you asked for.
# netstat -m
305/5152/26624 mbufs in use (current/peak/max):
305 mbufs allocated to data
292/3592/6656 mbuf clusters in use (current/peak/max)
8472 Kbytes allocated to network
On Fri, 22 Oct 2004, Stephane Raimbault wrote:
> The servers are busier today and error 49 is comming up frequently now.
What does "netstat -n | grep 127.0.0.1 | wc -l" show ?
You should probably try
sysctl -w net.inet.ip.portrange.first=49152
sysctl -w net.inet.ip.portrange.last=65535
or even
On Thu, 21 Oct 2004, Ronald F. Guilmette wrote:
> >I believe if you want to build a more maintainable, more adaptable,
> >more modularized program then you should avoid two things - the threads and
> >the signals. If you like to use a callback behaviour of the signals you could
> >easy implement i
I think this is because any bugs that are found are usually
communicated directly to us.
I think Randy has a better handle on how many people are using
this stack. I'm quite sure it is stable enough to go in to
-current.
While the SCTP API hasn't gone through last call, it's fairly
stable and we h
Thanks Igor,
I was running out of ports in the 1024-5000 range and setting my last port
to 65535 via sysctl did solve my problem.
In 4.10 what will sysctl -w net.inet.ip.portrange.randomized=0 do for me?
Is there any danger of me setting the port range from 1024 - 65535 ?
Thanks,
Stephane.
Igor S
Hi All,
I'm currently using a freebsd box running natd to forward port 80 to several
(5) web servers on private IP's.
I have discovered that natd doesn't handle many requests/second all that
well (seem to choke at about 200 req/second (educated guess))
There are other packet filtering options o
16 matches
Mail list logo
