I am new to socket programming. So currently I'm doing client-server connection in my computer. So the IP address for both client-server is 127.0.0.1. My question is, can I assign a specific client port to bind with the server? Instead of the OS chose the port number for me, can I assign it by myself? and if yes, can you help me on how to do this?
Thank you so much for your help.
You can make a client use a specific source address with bind, i.e. the same as you do for binding the server side address. But in most cases this additional effort is not worth it and might even result in troubles you did not had when using a system assigned port. Thus, don't do it unless it does not work without.
Related
What is the difference between a "tcp/socket" and "tcp/ip" connexion?
When you say that you use "tcp/ip", do you necessarily use a "tcp/socket"?
Thanks!
A socket is a general communication means provided by your
operating system.
There are many kinds of them, for very distinct purposes
(not only networking).
I guess that when you think about tcp/socket, you mean a
socket dedicated to the TCP protocol.
TCP/IP can be seen as two different things, depending on the context.
It can be the TCP/IP network stack as a whole: not only the TCP and IP
specific protocols but the set of protocols (and implementations) we
find around these.
Of course, the other way to see TCP/IP is to consider only the TCP
transport protocol relying on the IP network protocol.
The various operating systems implement many protocols
in the TCP/IP stack.
To use them, a programmer asks his/her operating system
a specific resource: a socket.
It's difficult to say more with few words.
Some books or online documentation could help go further.
I think you missing something in the question. Anyway in short...
TCP/IP is basically name given to protocol we (networking devices) follow it forms the fundamental of todays internet. It involves agreement between two devices how the want ro communicate eg. Which segment of a frame has what information as in the end its all just 10...
There are 5 layers (some argue 4) in this model one layer is Network Layer right at the middle of all and it generally uses IPv4.And just above this is our Transport Layer which may use TCP or UDP as protocol depending on service you want. So thats the summary of TCP/ IP as the most used set of protocols of all.
When connecting to a remote server your browser needs to know what kind of service he is about to get from that server eg. a video mail or file transfer or just a http page. Thats when a TCP/Socket comes into picture where there is a port no assigned for every service. Eg port 443 is for https and so on. All you need to do is open a socket connection over that port number on that machine
Remember if a particular port of a server is not in LISTEN mode you cannot connect to that application via that port
Eg. If a server serves its webpage it might not allow you to connect its port responsible for FTP.
From an introduction to Berkeley Sockets API in Tanenbaum's Computer Networks,
On the server side:
Newly created sockets by SOCKET primitive do not have network
addresses. These are assigned using the BIND primitive. Once a
server has bound an address to a socket, remote clients can connect to
it.
The reason for not having the SOCKET call create an address directly
is that some processes care about their addresses (e.g., they have
been using the same address for years and everyone knows this
address), whereas others do not.
Why is not having the SOCKET call create an address directly,
because some processes care about their addresses, whereas others
don't?
On the client side:
Now let us look at the client side. Here, too, a socket must first be
created using the SOCKET primitive, but BIND is not required since
the address used does not matter to the server.
why is BIND not required because the address used does not matter
to the server?
Why is not having the SOCKET call create an address directly, because some processes care about their addresses, whereas others don't?
Basically, because a strict client (eg. web browser) does not care what its local IP address/port is. By not requiring the SOCKET call to create/allocate an address, it can allow for the BIND call to actually never happen in the client context (where it often doesn't matter) but happen in the server context (where it greatly matters).
why is BIND not required because the address used does not matter to the server?
This is related to the first part of the answer above. A socket only needs to be bound to a specific address and port in order for something to reach out and connect to it. In many cases (such as a web browser), there is no reason for anything to be able to connect to it - it only needs to be able to connect to other systems (servers).
To make it a general principle, you only need to BIND a socket to an address when something else will need to connect up to it. You do not need to BIND a socket if it will only be connecting to something else.
Why is not having the SOCKET call create an address directly, because some processes care about their addresses, whereas others don't?
Because that's the way they designed it. Listening sockets don't need a target address, and in most cases they don't need a source address either (INADDR_ANY); and most client sockets don't need a specific source address either. Clients never need to call bind() at all in most cases. So putting the address into the socket creation API would be pointless.
The reason for not having the SOCKET call create an address directly is that some processes care about their addresses (e.g., they have been using the same address for years and everyone knows this address), whereas others do not.
I don't agree with this strange statement.
why is BIND not required because the address used does not matter to the server?
It's another strangely expressed statement. The source address of a connected socket can be determined automatically via the static IP routing tables. As long as the client can connect to the server at all, symmetry guarantess that the server can send back to the client on the same connection, so the actual source-address of the client doesn't matter specifically to either the cleint or the server application. It matters to TCP of course, otherwise it wouldn't exist.
I am testing a simple client/server application. My unit tests on client side need the server up, but I seem to be getting hangs (individual tests work, but not more than one).
As part of my tearDown(), I thought it would be good to close the server socket, but... since I have no way of getting access to the server object, from the client code, I can't do a simple: serverSocket.close(). That said, I do know what port number the socket is running on, with the port number alone, is it possible to close a socket, irrespective of where/how the object using it resides?
Sorry for what is probably a trivial question... thanks...
I suppose another related question is... can I create a socket based on a port number already in use?
No. You need to get the server software to close the port.
The only other alternative is killing the server: you can identify the process that has the port open with lsof or netstat, then kill the process. That's a brutal way to free a port though. In your case, you'd be much better off fixing your software not to hang!
If the socket is in your process, what you can do is iterate over all file descriptors from 0 to getrlimit(RLIMIT_NOFILE) and invoke getsockname() on each of them. If the call succeeds and the port number matches you have found your socket by port number (beware though, the may be multiple sockets with the same port number but bound to different addresses).
I'm in the process of trying to write a chat application and I have a few issues
that I trying to work out. The application is basically a chat application that works on a Lan. One client acts as the
host and other clients can connect to the host and publicly chat among themselves. I want also the option of a client starting
a private chat with an already connected client. So what is the best way for this to happen. For example should the request message (which
contains the ip address of client) route through the host and then if the requested client wants to connect , then they initiate the connection
using ip of the requesting client. Should this also be on a separate port number. Does it matter if your application uses a number of ports.
Or, when ever a client connects to a host, the host should send them a list of users with there ip addresses, and then the client can
attempt a connection with the other client for a private chat.
Hope this all makes sense. Any help would be appreciated
Thanks
If you are just interested in a quick-and-dirty chat facility that only needs to work over a LAN, I'd suggest having all clients send and receive broadcast UDP packets on a single well-known port number. Then no server is necessary at all, and thus no discovery is necessary either, and things are a lot simpler.
If you really want to go the client-server route, though, you should have your server (aka host) machine accept TCP connections on a single well-known port, and then have it use select() or poll() to multiplex the incoming TCP connections and forward any data that comes in from each incoming TCP socket to all of the others sockets. Clients can connect via TCP to the server at this well-known port, but the clients will have to have some way of knowing what IP address to connect to... either from having the user type in the IP address of the server, or by some discovery mechanism (broadcast UDP packets could be used to implement that). This way is a lot more work though.
I'm all for creating my own but depending on time constraints sometimes I look for alternatives like this I used it in a company I worked at before. It's really good. But if you decide to make your own you first have to map out a logic, structure, Database and so on before you even think about code..
I am using the Winsock API (not CAsyncSocket) to make a socket that listens for incoming connections.
When somebody tries to connect, how can I get their IP address BEFORE accepting the connection? I am trying to make it only accept connections from certain IP addresses.
Thanks
SO_CONDITIONAL_ACCEPT socket option. Here
Also, pretty sure it's available in XP and Server 2003, not just Vista.
Two reasons why I do not want to accept the connection in order to check the remote IP address:
1). The client would see that there is a listening socket on this port. If i decide to reject the client connection, I would not want them to know that there is a socket listening on this port.
2). This technique is not as efficient and requires more CPU, RAM, and network usage; so it is not good in case of a Denial Of Service attack.
When using ATM, the CONNECT ACK packet will come from the most recent switch, not the end client. So, you would have to call accept() on the socket, then look at the address (based on the passed addr_family), and at that point just close the socket. By the time it reaches the requester, it will probably just get a failure.
And I'm not sure how many resources you think this will take up, but accepting a connection is at a very low level, and will not really be an issue. It's pretty easy to drop them.
If you come under a DoS attack, your code CAN quit listening for a preset amount of time, so the attacker just gets failures, if you are so worried about it.
Does it really matter if the client knows there is a socket listening? Try using telnet to connect to your localhost on port 137 and see how fast the file sharing in windows drops the connection... (If you even have it enabled, and if I remembered the correct port number.. heh..)
But, at the SOCKET level, you are not going to be able to do what you want. You are talking about getting down to the TCP level, and looking at the incoming connection requests, and deal with them there.
This can be done, but you are talking about a Kernel driver to do it. I'm not sure you can do this in user-mode at all.
If you want Kernel help with this, let me know. I may be able to give you some examples, or guidance.
Just my own two cents, and IMVHO...
accept the connection, look at the IP, if it is not allowed, close the connection
Edit:
I'm assuming you're talking about TCP connection. When you listen to the port and a connection comes from a client, the API will perform the TCP 3-way handshake, and the client will know that this port is being listened to.
I am not sure if there is a way to prevent sending any packets (i.e. accepting the connection) so that you can look at the IP address first and then decide.
The only way I can think of is to do packet filtering based on the source IP at the network layer (using firewall, for example).