SCTP in KAME / Re: Removing T/TCP and replacing it with something simpler
> 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 lack of testers, SCTP-API standard, and SCTP-ready applications. #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP #application fails in compilation due to a change by SCTP. So it's #difficult to conclude that SCTP is already stable... So I'm not still sure if SCTP in KAME is complete and stable enough to merge into -current. (If someone can contribute to this kind of evaluation, it's quite appreciated, of course!) Thanks, SUZUKI, Shinsuke @ KAME Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Removing T/TCP and replacing it with something simpler
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 connections even if they can't initiate them). > o T/TCP requires different API calls than TCP to use it (UDP like). Only on the client side, I believe. > o T/TCP is not supported by any common network application. Prior to libfetch, fetch(1) used it by default. > Thus after the removal of T/TCP for the reasons above I want to provide > a work-alike replacement for T/TCP's functionality: Unlike your proposal, T/TCP is described in Internet RFCs (1379 and 1644) and well-known by the Internet community. > If you haven't read and/or unstood the link above or TCP/IP Illustrated > Volume 3 then please refrain from participating in this discussion! Nice. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Removing T/TCP and replacing it with something simpler
[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 PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Removing T/TCP and replacing it with something simpler
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 replacement for T/TCP's functionality: > > > > > > I disagree. I think the time spent here would be better spent on > > > working on an import of SCTP into the kernel, perhaps the KAME code > > > base would be a good starting point. > > > > Is the SCTP in KAME complete and stable? Are there any other (open > > source) implementations of it? > > SCTP in KAME is complete, stable and fully supported. > It is mainly developed by the SCTP RFC author, Randall Stewart. > > 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). Yes, but it depends on SCTP and we don't have SCTP in the kernel any time soon. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Removing T/TCP and replacing it with something simpler
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 server side > (i.e. they can receive T/TCP connections even if they can't initiate > them). Any fully TCP compliant stack should be able to accept T/TCP connection attempts. However if it didn't implement T/TCP itself it would simply do the standard 3WSH. So yes, you can use T/TCP from the client side towards any TCP server but you don't get any benefit from it. Neither Windows or Linux implement it. Windows during the NT4 days had a bug in the TCP stack that allowed something like T/TCP but it wasn't T/TCP and didn't work with T/TCP compliant clients. > > o T/TCP requires different API calls than TCP to use it (UDP like). > > Only on the client side, I believe. Yes, on the client side. sendto() instead of connect()+write(). > > o T/TCP is not supported by any common network application. > > Prior to libfetch, fetch(1) used it by default. Only if T/TCP was enabled on the machine (net.inet.tcp.rfc1644). > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > Unlike your proposal, T/TCP is described in Internet RFCs (1379 and > 1644) and well-known by the Internet community. Well known for its gaping security holes and left unimplemented on any other OS except FreeBSD. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: aio_connect ?
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 for each additional thread you want to run... > > That's OK. I don't mind. At least I don't think that I mind. (How big > must the separate event handler stacks be? If they are only, say, 2kB > apiece, then that's no big deal. Heck, my lowly desktop machine has a > zillion times that much main memory now!) The stacks are at least 8KB.. (but I think 12KB), plus any associated struct proc and other associated data... there is a tunable to increase the four, but of course, you'll take up more memory.. > >FreeBSD's kernel is inherently syncronous... > > Well, surely not entirely. I mean it fields interrupts, right? I'm talking about how it appears from userland.. This entire discussion has been about userland/kernel interface and nothing more.. bringing up a kernel/kernel interface is completely different... > >To handle what you want to do, we would need to completely rearchitect > >the FreeBSD kernel to make more things asyncronous.. > > I was under the impression that a lot of work had already gone in that > general direction in order to support SMP. No? For a lot of the kernel to kernel stuff, but many paths like ioctl's, read, write, etc. All those kernel interfaces will block in the kernel path till the resulting device returns... (is woken up).. There is no async interface as it hasn't been the Unix way(tm)... > >Going async can improve things, and with it, makes implementing a sync > >interface easy on top of it... > > Yes. (I realized myself last night that in theory, read(2) and write(2) > could be implemented, entirely in userland, on top of aio_read() and > aio_write() respectively.) > > >So the short of it is, no, FreeBSD at a low level does not support > >it... > > Oh well. It didn't hurt to ask. > > >Now, I know this isn't what you want, but I usually make my kevent > >use appear as if it's async... I use the udata pointer point to a > >struct which starts with a function pointer... Then when I get events > >back from kevent, I just have code that loops over the events, and calls > >the associated function pointer.. simulating a signal... > > I understand. Your event loop is really an event/dispatch loop. > > >Hope this helps... > > Well, you have certainly helped to clarify for me the various reasons > why it might be less than a good idea to use aio_*() function calls, > in abundance, on the current FreeBSD kernel. For that I do thank you. Even though aio_ needs help, it appears that some other people are working on improving it right now... Doug Ambrisko posted a message to -current about some patches to make aio_ work with kqueue. 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 delivered the signal.. Though now that kqueue has been locked down we can revisit this.. 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, and that isn't enough for what you want.. since even if you did get a signal, it'd degenerate into an event/dispatch loop at you stated above.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: aio_connect ?
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 delivered the signal.. Though now that kqueue has been locked > down we can revisit this.. I misspoke, it was Alfred Perlstein who did this work. see v1.71 and v1.72 of src/sys/kern/kern_event.c.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: aio_connect ?
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 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? If not, then there are effectively 4 billion+ different signal numbers that could be used by a programmer. Such usage might not be fully standard-conformant, but it might work OK, nontheless. (In fact, one might even be able to use _most_ typical pointer values as if they were signal numbers, simply by casting them to ints before use.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: aio_connect ?
< 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 and in the API, as bits in fixed-size bitmaps. POSIX real-time signals, if we implemented them, would at least give you the opportunity to queue signals, with unique ancillary data attached to each instance. We have all the mechanism to do this in the user-kernel interface; it's just not implemented in the kernel. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Removing T/TCP and replacing it with something simpler
> 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 and then decide that you don't really care if it gets across the network (say, because it got lost and has taken too long to retransmit and so the data is out of date). Without a Big Hack, I cannot envision TCP doing something like this. What am I missing? Thanks, allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ pgpSZKQsnb5PD.pgp Description: PGP signature
Re: Error 49, socket problem?
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 (42% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines # ifconfig -a em0: flags=8843 mtu 1500 options=3 inet 10.0.12.15 netmask 0xffe0 broadcast 10.0.12.31 inet6 fe80::230:48ff:fe29:7f48%em0 prefixlen 64 scopeid 0x1 ether 00:30:48:29:7f:48 media: Ethernet 100baseTX status: active em1: flags=8802 mtu 1500 options=3 ether 00:30:48:29:7f:49 media: Ethernet autoselect status: no carrier lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 faith0: flags=8002 mtu 1500 # netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.0.12.1 UGSc 588 1292em0 10.0.12/27 link#1 UC 130em0 10.0.12.1 00:00:5e:00:01:05 UHLW 5880em0 1177 10.0.12.8 00:0c:f1:77:a5:d8 UHLW 97 7723205em0229 10.0.12.10 00:30:48:29:7f:34 UHLW0 22em0552 10.0.12.11 00:30:48:29:80:38 UHLW0 1165712em0987 10.0.12.12 00:30:48:29:80:d4 UHLW0 172em0 1018 10.0.12.13 00:30:48:27:75:61 UHLW 215 35228169em0 1193 10.0.12.14 00:30:48:29:80:84 UHLW1 27992157em0959 10.0.12.15 00:30:48:29:7f:48 UHLW1 12597865lo0 10.0.12.22 00:30:48:23:bb:f0 UHLW 2125 303510829em0 1034 10.0.12.23 00:e0:81:21:1b:78 UHLW0 242em0697 10.0.12.26 00:0d:61:03:80:98 UHLW0 8736em0975 10.0.12.30 00:c0:4f:9e:b9:c7 UHLW0 848em0 1003 10.0.12.31 ff:ff:ff:ff:ff:ff UHLWb 0 2347026em0 127.0.0.1 127.0.0.1 UH 1022 153926288lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%em0/64 link#1UC em0 fe80::230:48ff:fe29:7f48%em0 00:30:48:29:7f:48 UHL lo0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 fe80::1%lo0 link#3UHL lo0 ff01::/32 ::1 U lo0 ff02::%em0/32 link#1UC em0 ff02::%lo0/32 ::1 UC lo0 # uptime 1:39PM up 31 days, 3:02, 3 users, load averages: 1.34, 1.27, 1.07 # sysctl -a | grep socket kern.ipc.maxsockets: 12328 socket: 192,12328, 5320, 1080, 124222928 jail.socket_unixiproute_only: 1 # tail -f /wwwlogs/httpd-error.log [Fri Oct 22 13:39:18 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:20 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:20 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:21 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:24 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:39 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:39 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:40 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:43 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:43 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed what else can I check for here... it's quite mysterious as several network based apps on the server fail, yet nothing in /var/log/messages indicating a problem. From: [EMAIL PROTECTED] To: "Stephane Raimbault" <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: Erro
Re: Error 49, socket problem?
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 sysctl -w net.inet.ip.portrange.first=1024 sysctl -w net.inet.ip.portrange.last=65535 And after you upgrade to 4.10 do not forget to set sysctl -w net.inet.ip.portrange.randomized=0 Igor Sysoev http://sysoev.ru/en/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: aio_connect ?
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 it without any signal. > > OK. I'll bite. How? I'm sure you know it. Sorry, English is not my native language so I may tell you only shortly. You can use two notification models. First is the socket readiness for operations, second is the operation completeness. In the first model you use usual read()/write() operations and learn readiness using select()/poll()/kevent(). In the second model you use aio_read()/aio_write() operations and learn about their completeness using aio_suspend()/aio_waitcomplete()/kevent(). After you have got the notifications you would call your callback handlers as well as the kernel would call your signal handlers. The difference between your code and kernel is that your code always calls handlers in the well known places that allows to avoid the various race conditions. The kernel may call the signal handler any time if the signal is not blocked. Igor Sysoev http://sysoev.ru/en/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler
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 have both "converted" many applications from TCP to SCTP using the sockets API, as well as had portability between the KAME SCTP stack and the linux stack for some test applications used at the last interop event (except for the standard sockets issues that one runs into even for TCP like no sin_length field in the sockaddr struct). The same stack has also been ported to Mac OSX as a native kernel build as well as an loadable/unloadble NKE w/a minor kernel change. I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. The major changes to our SCTP code when it gets committed into KAME has been that of code format/style. What is the existing criteria for a measure of "stability"? regards, --peter SUZUKI Shinsuke wrote: 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 lack of testers, SCTP-API standard, and SCTP-ready applications. #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP #application fails in compilation due to a change by SCTP. So it's #difficult to conclude that SCTP is already stable... So I'm not still sure if SCTP in KAME is complete and stable enough to merge into -current. (If someone can contribute to this kind of evaluation, it's quite appreciated, of course!) Thanks, SUZUKI, Shinsuke @ KAME Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" smime.p7s Description: S/MIME Cryptographic Signature
Re: Error 49, socket problem?
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 Sysoev wrote: 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 sysctl -w net.inet.ip.portrange.first=1024 sysctl -w net.inet.ip.portrange.last=65535 And after you upgrade to 4.10 do not forget to set sysctl -w net.inet.ip.portrange.randomized=0 Igor Sysoev http://sysoev.ru/en/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" _ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
using natd to load balance port 80 to multiple servers
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 on FreeBSD and I wonder if I can use them to do what I'm trying to do with natd. Would someone be able to point me to documentation or help me have either ipf/ipfw/pf forward port 80 traffic to private space IP's? Is there a better way of split port 80 traffic across multiple webservers that has elduded me? Other then a comercial content switch that is :) I've worked with the loadd port and ran into some problems, so I resulted in simply using some natd syntax to forward port 80 traffic to multiple servers... Now that seems to have run to it's limitation and I'm wondering if I can do the same thing with ipf/ipfw/pf as I believe that might be a bit more efficient. Any feedback would be appreciated... Thanks, Stephane. _ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
