When I called connect() in linux, I saw that the socket was bound to the ip of the interface related with the default gateway. I mean It seems like to call bind() internally when called connect(). Is it really call bind()?
I tried this with udp socket
Also, If I call connect(), Does it always checks routing table to know that destination ip is valid?
It seems like to call bind() internally when called connect(). Is it really call bind()?
Yes, connect() will bind() the socket to a local interface and ephemeral port, but only if the socket is not already bound.
Also, If I call connect(), Does it always checks routing table to know that destination ip is valid?
Not for UDP, no. connect() on a UDP socket merely assigns a static peer IP/port to the socket, nothing more. If you then try to send() on a connected UDP socket, and the destination is invalid, the packet will not be delivered, and send() may return an error code.
Related
As side question, can bind and listen be reversed? E. g. I'd like to keep port or file descriptor for a while and then rebind and listen again?
I'm also curious about rationale of this design. In all examples I've seen, stream sockets are bound first and then start listening. I.e. bind, and listen are to be called separately whereas socket is not used between then in any ways. Is that because these calls are more or less separate and orthogonal from OS point of view?
You cannot listen() on an unbound socket, and you cannot bind() a socket that is already bound. They are separate operations because bind() can be used for both clients and servers, whereas listen() can only be used for servers.
I was brushing up my sockte programming knowledge and came across a doubt.
First let me explain my understanding of sockets.
Socket binding associates the socket with port.
Socket binding helps kernel to identify the process to whom it should forward the incoming packet.
In connection oriented communication socket establishment is as below
At server side
socket()-->bind()-->listen()-->accept().....
client side is
socket()-->connect-->......
My question is why client need not bind to a socket. In client case if it send a request it has to get a response to its socket and kernel has to forward it to its process.For these things to happen isn't binding needed?If not how kernel will understand to whom to send the response packet?
Also in connection less client call bind socket.Why is it needed here?
My question is why client need not bind to a socket.
Because the kernel does the bind automatically when you call connect(), if you haven't bound the socket yourself.
Also in connectionless client call bind socket. Why is it needed here?
Because otherwise the socket isn't bound to an IP address:port, so it can't send or receive anything. It has no path to the outside world.
You always open a socket first. This is the path through the kernel. The connect call for say TCP happens after the socket is made.
Look at TCP versus UDP clients.
TCP
s = socket(options....)
connect(s)
send(s, data)
UDP
s = socket(options....)
send(s, data)
bind("0.0.0.0", 0) (all interfaces, any port) is implicit if you call connect(...) or listen(...) without an explicit bind(...).
All sockets must be bound to a local port even when connectionless so that bi-directional communication is possible (even if you're not going to do so).
is it possible in any common platform - say, in Windows - to write a servient process that creates a socket, binds it to exactly one local "address:port" (fixed), and then:
use it to listen for incoming connections (on the specified port)
while at the same time
use it as a client socket to connect to some other servient (having source port identical to the one it exposes to others) ?
that is (sorry for the syntax abuse):
mySocket=socket(); mySocket.bind(myaddress, 3000);
mySocket.connectTo(neighbour, whateverport); // and present to others as port 3000
mySocket.listen(); // and it listens on 3000
mySocket.accept();
?
iirc, it's not even possible/advisable to try, even in the case an API wouldn't complain, but maybe it's me that is playing too much by the book... so I thought of asking you
thanks a lot!
No, a socket cannot be used for both listening and connecting at the same time. connect() will return a WSAEINVAL error if listen() was already called, and listen() will return a WSAEISCONN error if connect() was already called. You need to use separate sockets.
And if you could, there's be all kinds of troubles that crop up. For example, if select() returns that the socket is readable, do you do a recv() or an accept()? You want 2 sockets to play those two roles.
What advantage is there in one socket? For example, if you were hoping to do a blocking read until something interesting happens (incoming connection, incoming data), there are alternatives. In that example, you'd use select() to block on two sockets at once. The result from select() tells you which socket is ready. That tells you if you want to accept() a new connection from the one socket or recv() new data from the other socket.
The winsock function socket expects as third parameter the protocol what usually is IPROTO_TCP for socket type SOCK_STREAM and IPROTO_UDP for socket type SOCK_DGRAM. When I pass a 0 value as the protocol parameter, TCP and UDP work as expected.
SOCKET s = socket(AF_INET, SOCK_DGRAM, 0)
// s is a valid socket
What is the IPROTO_IP protocol parameter value meant to? If it's only intented to be used with SOCK_RAW, why is there this kind of redundancy?
socket(AF_INET, SOCK_STREAM, IPROTO_TCP);
socket(AF_INET, SOCK_DGRAM, IPROTO_UDP);
What actually does the protocol parameter specify? when I can just use another value, it looks like that it's unimportant.
I want to send UDP packets (including broadcasts) from a PC with more than one netword card to a specific ethernet segment. While the IP routing normally select the network card (and source address) I would like specify the adapter(s) and think about raw sockets or any other means to achieve this goal. Probably this IPPROTO_IP may help in this case.
I think the documentation for socket (which can be found here: http://msdn.microsoft.com/en-us/library/ms740506(VS.85).aspx) is pretty clear on what the value is for and why passing 0 is fine if you don't care.
A situation where you might want to pass something different is if you wanted to set up a socket for an unusual connection type; such as bluetooth, or if you wanted to create a PGM reliable multicast socket, etc.
Your second question is unrelated to raw sockets or the protocol parameters. What you need to do is simply bind your socket to the address of the local interface that you want to use; so rather than binding to INADDR_ANY and allowing the stack to decide for you, you tell it which interface to use.
I am creating a UDP socket client in C (unicast) and is wondering why recvfrom() has a struct sockaddr * argument in which in the man page says,
A null pointer, or points to a sockaddr structure in which the sending address is to be stored.
Is it possible that I could receive a message from a different server other than the one I sendto? If yes, how to create this scenario?
If no, is it correct to say that this argument is only useful when broadcast mode is used?
Yes, this is perfectly possible. The reason for this is that UDP is not stream-based, but packet-based. Every packet is treated without any history (other packets sent or received).
For this reason you may also open a UDP port and then send packets to different hosts from it. However, I do not remember how well this is supported by the API.
The UDP socket will recvfrom() any host sending to this one with correct port unless you explicitly connect(), in which case you can just write() and read(), and get errors upon received ICMP messages.
Considering you always have two parties in UDP, it seems rather obvious that someone has to recvfrom() first.