[M3devel] socket options?

[Jay K]

Realize that the socket API is almost identical
on Win32 and Posix. And the Modula-3 libraries
are therefore almost identical -- unfortunately duplicated..


SocketPosix.m3:


PROCEDURE InitStream (fd: CARDINAL)
  RAISES {OSError.E} =
  (* We assume that the runtime ignores SIGPIPE signals *)
  VAR
    one : int := 1;
    linger := struct_linger{1, 1};
  BEGIN
    EVAL setsockopt(fd, SOL_SOCKET, SO_LINGER,
                    ADR(linger), BYTESIZE(linger));
    EVAL setsockopt(fd, IPPROTO_TCP, TCP_NODELAY,
                    ADR(one), BYTESIZE(one));

    MakeNonBlocking (fd);
  END InitStream;


PROCEDURE MakeNonBlocking (fd: INTEGER)
  RAISES {OSError.E} =
  VAR
    old_mode := fcntl (fd, F_GETFL, 0);
    new_mode := Word.Or (old_mode, M3_NONBLOCK);  
  BEGIN
    IF fcntl (fd, F_SETFL, new_mode) = -1 THEN
      IOError (Unexpected);
    END;
  END MakeNonBlocking;


SocketWin32.m3
PROCEDURE InitSock (sock: SOCKET) =
  (* We assume that the runtime ignores SIGPIPE signals *)
  VAR
    one: int := 1;
    linger := struct_linger{0, 0};
  BEGIN
    EVAL setsockopt (sock, SOL_SOCKET, SO_LINGER,
                     ADR(linger), BYTESIZE(linger));

    (**** WinSock documentation warns that this may cause problems
    ****)
    EVAL setsockopt (sock, IPPROTO_TCP, TCP_NODELAY,
                     ADR(one), BYTESIZE(one));
  END InitSock;



The meaning of struct_linger is the SAME on Posix and Win32.
The fact that Modula-3 passes "opposite" parameters is clearly broken.



so, obvious questions:
  Do we need either setsockopt?
  Clearly if we use SO_LINGER, we should use the same parameters.
  TCP_NODELAY seems to be generally discouraged. But it seems to
  usually have a real meaning, and removing it here would break things?
  In particular, it, like, turns off buffering. It means if you do
  write with just one byte, it will be sent immediately. If that is
  the "last" byte for a "while", ok. If you are making a series of
  small writes, it pays very much to coalesce them into fewer larger writes,
  at the cost of delaying the earlier writes.
  

Here is an example of implicity discouraging it:


http://smalltalk.gnu.org/project/issue/119

"The tcp delay, aka. nagles algorithm has it's applications and disabling
it should be done only in special applications (eg. where low-latency for is required) IMO.
"


Doing this unconditionally for all sockets seems wrong.



On the other hand:
http://en.wikipedia.org/wiki/Nagle%27s_algorithm


paraphrasing part of it: As long as the application does not issue small writes, it is ok.


At least this part we do the same for Posix and Win32.



 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130205/8235ed5d/attachment-0001.html>