🔒 Locked
Basic Socket Questions
Advertisement
Original Post
1) What is the different between connect() and bind()? Is connect() used for TCP, but not UDP, right? It is only needed to establish a physical connection with a server, right? 2) What is the difference between listen() and accept()? As far as I can tell, accept() can grab an incoming connection and start receiving data on it without needing listen(). I'm using Python's socket module, but the method names should be the same as the Unix C library that the module is based on.
Here's another one:
3) Is it possible for a socket to send data to itself?
e.g.
When this code is executed, the sendto() call throws this exception: (10049, "Can't assign requested address")
3) Is it possible for a socket to send data to itself?
e.g.
[source language="python"]s = socket(AF_INET, SOCK_DGRAM) # create a UDP socketaddress = ("localhost", 25000)s.bind( address )s.sendto(someData, address)When this code is executed, the sendto() call throws this exception: (10049, "Can't assign requested address")
I'm familiar with the sequence of events, but I'm trying to figure out what listen() actually does. It doesn't seem to be needed.
Quote:
Original post by doctorsixstring
1) What is the different between connect() and bind()?
bind attaches a socket to an interface and/or port; it does not do the same as connect().
bind() is optional for UDP sockets and TCP client sockets. For some other types it is mandatory (e.g. TCP listening sockets).
Quote:
Is connect() used for TCP, but not UDP, right?
connect() is used on stream-oriented protocols including TCP but not UDP.
Quote:
It is only needed to establish a physical connection with a server, right?
It doesn't establish a physical connection with anything. It's only logical.
Quote:
2) What is the difference between listen() and accept()?
They are completely different. listen() tells a bound stream socket to become a listen socket. This is not a fully established socket (nor can it ever be), but is then only ever used to accept() new established stream sockets.
Neither of them make any sense for non-stream sockets.
Quote:
As far as I can tell, accept() can grab an incoming connection and start receiving data on it without needing listen().
No, it cannot. accept() only works on sockets which are already listen()ing. Sockets which are listening can never do anything except have accept() done to them.
Quote:
I'm using Python's socket module, but the method names should be the same as the Unix C library that the module is based on.
Probably.
The socket interface is used for things other than IP, especially on Unix / Linux. There are heaps of other protocols which are accessible through socket. This includes (e.g) Unix sockets and other things.
Not all operations make sense on all types of socket.
- Non connection oriented sockets can be bound (in some cases, depending on address family), but connect() doesn't do anything other than set the default transmit address.
- Connection oriented sockets can listen() and connect()
- Listening sockets can be used to accept() and nothing else.
Mark
Hey ! Doctorsixstring
you seem to be confused about the basics (try to go through the protocols TCP/UDP )
ok one of the difference between a server and client server "listens" for connections , client looks for a server .A listening socket can accept incoming connections .
can a socket send data to itself ...
in theory it should be possible ,
in your code try use INADDRANY or 0.0.0.0 as the address
and also you need to loop in recvfrom() in order to recieve packets
hope this helps
you seem to be confused about the basics (try to go through the protocols TCP/UDP )
ok one of the difference between a server and client server "listens" for connections , client looks for a server .A listening socket can accept incoming connections .
can a socket send data to itself ...
in theory it should be possible ,
in your code try use INADDRANY or 0.0.0.0 as the address
and also you need to loop in recvfrom() in order to recieve packets
hope this helps
Quote:
Original post by doctorsixstring
Here's another one:
3) Is it possible for a socket to send data to itself?
e.g.
*** Source Snippet Removed ***
When this code is executed, the sendto() call throws this exception: (10049, "Can't assign requested address")
It is possible, but not like that. To send data to yourself, rather than sending it to your own address, you need to send it to the special Loopback address. This is typically 127.0.0.1
What listen() is needed for:
A socket does not accept incoming SYN packets until you have called listen() on it. It's perfectly valid to bind() a socket that you then call connect() on to forge an outgoing connection -- in fact, TCP NAT punch-through depends on that feature.
A socket that has listen() on it has some backlog (OS dependent, possibly dependent on the argument to listen()) of incoming connections that can be de-queued by a call to accept() on the socket. However, until listen() has been called, that queue does not exist, and the socket does not accept incoming connections.
Without listen() in the API, the API would either need to auto-create this queue the first time you call accept() (which is too loose a semantic for most systems programmers, plus you can't pass the "backlog" argument in), or you have to accept incoming connections on all sockets that have been bound with bind() (which means you'd accept connections even when you don't want to).
A socket does not accept incoming SYN packets until you have called listen() on it. It's perfectly valid to bind() a socket that you then call connect() on to forge an outgoing connection -- in fact, TCP NAT punch-through depends on that feature.
A socket that has listen() on it has some backlog (OS dependent, possibly dependent on the argument to listen()) of incoming connections that can be de-queued by a call to accept() on the socket. However, until listen() has been called, that queue does not exist, and the socket does not accept incoming connections.
Without listen() in the API, the API would either need to auto-create this queue the first time you call accept() (which is too loose a semantic for most systems programmers, plus you can't pass the "backlog" argument in), or you have to accept incoming connections on all sockets that have been bound with bind() (which means you'd accept connections even when you don't want to).
On sending data from a socket to itself... with datagram sockets (e.g. UDP) this is usually possible.
You should target an IP address which the socket is bound to, e.g. loopback but ONLY if you've bound the socket to the loopback interface (or INADDR_ANY).
If a socket is bound to a specific interface, it won't receive packets sent to another interface even if they're on the same port number and protocol.
It is normal practice to bind server sockets to INADDR_ANY on a specific port, in which case any interface address would do, including loopback.
Mark
You should target an IP address which the socket is bound to, e.g. loopback but ONLY if you've bound the socket to the loopback interface (or INADDR_ANY).
If a socket is bound to a specific interface, it won't receive packets sent to another interface even if they're on the same port number and protocol.
It is normal practice to bind server sockets to INADDR_ANY on a specific port, in which case any interface address would do, including loopback.
Mark
Thanks for the help, guys. I'm not sure how I missed Beej's Guide to Network Programming Using Internet Sockets, but it seems like it answers most of my questions. Some of the replies in this thread defeinitely give more detailed info, though (thanks hplus0603!). I read the FAQ, honest!
I'm not sure why I thought this. I just wrote a little test script, and the call to accept() failed with an "Invalid Arguments" error when I commented out the previous call to listen().
Quote:
Original post by drsixstring
I'm trying to figure out what listen() actually does. It doesn't seem to be needed.
I'm not sure why I thought this. I just wrote a little test script, and the call to accept() failed with an "Invalid Arguments" error when I commented out the previous call to listen().
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement