booloo@lll-crg.llnl.gov (Mark Boolootian) (12/08/90)
I have been under the impression that the window presented by a TCP receiver is tied to the amount of socket buffer available. Thus, if I setsockopt() and change the socket receive buffer size, I would note a change in the size of the receive window. Unfortunately, after looking at some ethernet traces, I have found this not to be the case. I have looked (briefly and without a lot of comprehension) at the BSD4.3 (Ultrix flavored) source and it sure looked like the receive window was tied to the size of the socket buffer. But the window presented by our vax is always 4K, even when I set a receive buffer size of 32K. So my question is: Is there any way for an application (who wishes to receive data) to increase the window presented to the sender? Many thanks in advance, mb booloo@lll-crg.llnl.gov btw, I had previously asked how it was possible for bind() to return EADDRINUSE once SO_REUSEADDR had been set on a socket. Unfortunately, nobody has been able to provide (what I consider to be) a satisfactory answer. I'd still really like to know...
enag@ifi.uio.no (Erik Naggum) (12/10/90)
In article <87439@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
btw, I had previously asked how it was possible for bind() to
return EADDRINUSE once SO_REUSEADDR had been set on a socket.
Unfortunately, nobody has been able to provide (what I consider to
be) a satisfactory answer. I'd still really like to know...
It seems, after discussing this with numerous people for a while
(whose names are unfortunately hidden in my mailbox at work, not here
at the U), that the rationale was to be able to find sockets that were
not in use, without adding a lot of overhead to the connect() call.
Instead, if a _port_ is in use when you do the bind() with port
specified, you get EADDRINUSE. This doesn't make much sense in normal
TCP/IP ways, but the folks at Berkeley had this great idea about
security with rlogin (etc), so they demanded that the port number of
the caller be in the range 512-1024, i.e. within the privileged range
in their own systems. Now, how to find an unused port in a specific
range? Trial and error, basically.
The half-way right way to do it, however, is a system call specifying
the low end and the high end of the range you need. The kernel knows
which ports are in use, and can give you a port in the range you
request. The kernel can also ensure that you don't get a port which
has just recently beed closed unilaterally.
Finally, the truly _right_ solution is not to depend on port ranges at
all, rendering the whole stupid question moot.
I hope this has cleared things up a bit, although I would agree that
the rationale is utterly bogus, and doesn't make any sense, except in
the absence of rational design. BSD = Bogus Software Design.
--
[Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions. Wail: +47-2-836-863 ISO 8859-1: [\] FXE FXE {|} fxe fxemurthy@la.excelan.com (M.D. Srinivas Murthy) (12/27/90)
In article <87439@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes: > >btw, I had previously asked how it was possible for bind() to return EADDRINUSE >once SO_REUSEADDR had been set on a socket. Unfortunately, nobody has been able >to provide (what I consider to be) a satisfactory answer. I'd still really like >to know... It is possible for bind() to return EADDRINUSE evenif the SO_REUSEADDR option is set for the socket if the address is already bound to another socket which is not in connected state. Once the socket is connected you can bind the same address to another socket using SO_REUSEADDR option. murthy