Strange Linux socket protocols behaviour
NickName:Doddy Ask DateTime:2011-09-08T18:37:43

Strange Linux socket protocols behaviour

I'm a little confused about the difference between the definitions of protocols on Linux when using socket(). I am attempting to listen for connections over TCP using socket(PF_INET, SOCK_STREAM, proto), where proto is (in my mind) disputed, or at least seems odd.

From <netinet/in.h>:

...
IPPROTO_IP = 0,    /* Dummy protocol for TCP.  */
...
IPPROTO_TCP = 6,       /* Transmission Control Protocol.  */
...

Agreed with by /etc/protocols:

ip      0       IP              # internet protocol, pseudo protocol number
hopopt  0       HOPOPT          # hop-by-hop options for ipv6
...
tcp     6       TCP             # transmission control protocol
...

I learned from an online tutorial, and also from the man page tcp(7) that you initialise a TCP socket using

tcp_socket = socket(AF_INET, SOCK_STREAM, 0);

which works absolutely fine, and certainly is a TCP socket. One thing about using the above arguments to initialise a socket is that the code

struct timeval timeout = {1, 0};
setsockopt(tcp_socket, 0, SO_RCVTIMEO, &timeout, sizeof(timeout); // 1s timeout
// Exactly the same for SO_SNDTIMEO here

works absolutely fine, but not after replacing all protocol arguments (including in socket()) with IPPROTO_TCP, as opposed to IPPROTO_IP which they have, as above.

So after experimenting with the difference, I've needed to ask a few searching questions:

  1. Why, when I replace all protocol arguments with IPPROTO_TCP, do I get error 92 ("Protocol not available") when setting timeouts, when protocol 0 is apparently just a 'dummy' TCP?
  2. Why does socket() require the information of whether it should be a stream, datagram or raw socket when that information is (always?) implicitly known from the protocol, and vice versa? (i.e. TCP is a stream protocol, UDP is a datagram protocol, ...)
  3. What could be meant by "dummy TCP"?
  4. What is hopopt, and why does it have the same protocol number as 'ip'?

Many thanks.

Copyright Notice:Content Author:「Doddy」,Reproduced under the CC 4.0 BY-SA copyright license with a link to the original source and this disclaimer.
Link to original article:https://stackoverflow.com/questions/7346695/strange-linux-socket-protocols-behaviour

Answers
Per Johansson 2011-09-08T11:17:47

Giving 0 as protocol to socket just means that you want to use the default protocol for the family/socktype pair. In this case that is TCP, and thus you get the same result as with IPPROTO_TCP.\n\nYour error is in the setsockopt call. The correct one would be\n\nsetsockopt(tcp_socket, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout)); // 1s timeout\n\n\nthe 0 there is not for protocol, but for option level. IPPROTO_TCP is another option level, but you can't combine that with SO_RCVTIMEO. It can only be used together with SOL_SOCKET.\nThe ones you use with IPPROTO_TCP are the ones listed in tcp(7), e.g. TCP_NODELAY.",


More about “Strange Linux socket protocols behaviour” related questions

Strange Linux socket protocols behaviour

I'm a little confused about the difference between the definitions of protocols on Linux when using socket(). I am attempting to listen for connections over TCP using socket(PF_INET, SOCK_STREAM, p...

Show Detail

Behaviour of Protocols with Self

I was recently reading Protocols, Generic Type Constraints and Arrays in Swift. My question concerns the following two examples from the blog: The code: protocol MyProtocol1 { var myValue: S...

Show Detail

Linux app sends UDP without socket

fellow coders. I'm monitoring my outgoing traffic using libnetfilter_queue module and an iptables rule ipatbles -I OUTPUT 1 -p all -j NFQUEUE --queue-num 11220 A certain app, called Jitsi (which ...

Show Detail

HTTP request, strange socket behaviour

I experience strange behavior when doing HTTP requests through sockets, here the request: POST https://example.com:443/service/XMLSelect HTTP/1.1 Content-Length: 10926 Host: example.com User-Agent:

Show Detail

Strange behaviour of a Socket attribute in a Moose Object

I have a Moose Object which has a IO::Socket::INET object as one of its attributes: has socket =&gt; ( is =&gt; 'ro', required =&gt; 1, lazy =&gt; 1, isa =&gt; 'IO::Socket::INET&#

Show Detail

strange behaviour of git

i have strange behaviour of git - push is working, but clone is not :( alec$ git clone git://host/repo.git Initialized empty Git repository in /Users/alec/Temp/repo/.git/ host[0: x.x.x.x]: errno=

Show Detail

Strange behaviour between EF 6 and ObservableCollection

I have a behaviour between EF 6 and my WPF ViewModel, which I don't understand: My ViewModel has an ObservableCollection Protocols. In the ViewModel's constructor I call Protocols = new

Show Detail

TCP retransmission on RST - Different socket behaviour on Windows and Linux?

Summary: I am guessing that the issue here is something to do with how Windows and Linux handle TCP connections, or sockets, but I have no idea what it is. I'm initiating a TCP connection to a pi...

Show Detail

Strange delay on Win UDP socket during GC

When closing a UDP socket which previously sent to a host known by my router, it takes forever to close. What is going on, and how can I circumvent? $ python Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb...

Show Detail

Strange program behaviour after closing a Linux socket

I'm studying Linux/UNIX sockets, so I wrote a very simple "game" based on it, called "21 matches". There's a heap that consists of 21 matches, and each player takes one, two or three matches from i...

Show Detail