> do 'netmask 255.255.255.255' instead or 'netmask 0x' since this is
> an alias... for some reason otherwise services may not bind to the ip
> correctly
Why would this be? The two are numerically equivalent.
-Jon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
If a UDP socket selects readable, am I assured that the next read call will not
block?
If a socket is nonblocking, can I use setitimer and handle SIGALRM, and be
assured that the process will not be put to sleep waiting for I/O on the socket,
thus returning EINTR due to the signal?
--
Jonathan
> > $local_socket = sockaddr_in($port, inet_aton(INADDR_ANY) );
> >
> > to
> >
> > $local_socket = sockaddr_in($port,INADDR_ANY );
> >
> > now is working fine on FBSD 3.x.
>
> Ah. Ick. Perl. Bleh.
He'd have the same problem in C (except that the compiler would catch it -
INADDR_ANY is not a st
> > Data CAN be lost if the TCP connection is RST. It has nothing to
> > do with the ordering of accept() with respect to close().
>
> Please educate me: how would RST come into this discussion at all?
> The client does connect() write() close(), there is no forced
> connection termination involv
I would like to preempt corrections to the effect that it is currently
impossible for accept to return both an error code and a socket to read the data
from. It sounds like there may be a bug in the behavior of accept w.r.t Unix
Domain sockets. For TCP, if the client sends data, then closes with
cd /usr/ports/net/nemesis
make install
Nemesis (http://www.packetninja.net/nemesis/) is a command line tool that can
easily generate syn packets; if you want a flood, write a script.
There is also /usr/ports/net/libnet
http://www.packetfactory.net/Projects/Libnet/
- it is used by nemesis and is
#!/bin/sh
i=5; while [ $i -lt 50100 ]; do nemesis-tcp -S 209.68.199.246 -D
209.68.199.242 -fS -x $i -y 25; i=$(($i + 1)); done
... seems to work fine; a perl script would give a more legible for loop though
;)
--
Jonathan Graehl
email: [EMAIL PROTECTED]
web: http://jonathan.graehl.org
-S 209.68.199.246 -D
> 209.68.199.242 -fS -x $i -y 25; i=$(($i + 1)); done
>
> ... seems to work fine; a perl script would give a more legible for
> loop though
> ;)
>
> --
> Jonathan Graehl
> email: [EMAIL PROTECTED]
> web: http://jonathan.graehl.org/
To Unsubscribe: send mail
cessing as
fast as possible, and that in-kernel servers (NFS and the TUX webserver) are
blazingly fast.
I do have Linux 2.4 running on an old machine, but I have no intention of taking
down my FreeBSD box to dual boot Linux just to compare penis size. Has anyone
recently done so?
--
Jonatha
ion. If the kqueue API is overengineered, well, then, so is the
Berkeley Sockets API.
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
6_addr from
a sockaddr*? (I believe Ethernet and other address types may also be mapped
into the IPv6 address space).
I do realize that, if possible, transmission of protocol addresses should be
avoided because of evils such as NAT (although IPv6 may one day give us a truly
global address space)
rent port;
however, this is less than transparent as far as NAT is concerned.
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
and
process it in a synchronous fashion outside of my event handling logic. Relying
on undocumented behavior makes me nervous. Are there any other system calls I
should worry about returning EINTR even when I specify SA_RESTART?
Thanks,
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe:
possibility, or else silently
reliant on process termination freeing all descriptors).
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Thanks for the suggestion - it does fit the bill, although I have to
getsockopt(SO_SNDBUF on a per-socket basis (I'm using the kqueue
NOTE_LOWAT, which doesn't trigger if I supply a very large number - the
exact SO_SNDBUF needs to be used). I'd honestly just prefer to have the
kernel close the so
> > Problem: close() does not perform an orderly shutdown, does
> not resend
> > unacknowledged data - responds with RST to data/acks sent to me
>
> I suggest that this is a bug.
That is my feeling as well. I am well aware that depending on the
transport layer to ensure delivery of the "last
does play a game of Tribes now and then, so unpredictable
10ms delays would not be fun for them.
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
17 matches
Mail list logo
