In my application, a client connects to the server at a given port and host.
Now, I want to know the port number that is opened at the client's end.
How can I get this information ?
Also, at the server end, can I also get the port number at which the client is connecting to ?
Basicaly, I want to send some extra information to the server when the client connects.. So, I will dump a file when a client is created with the file name as the port number of the client and at the server end, I will again try reading a file whose name is the port number of the client...
Now, I want to know the port number that is opened at the client's end.
Also, at the server end, can I also get the port number at which the client is connecting to ?
These questions seem to be the same to me. Unless you mean the port of the server, which you have to specify on both ends (and therefore already know).
Yes, you can get in your server the port of the connecting client along with the IP-address.
//boost::asio::ip::tcp::socket _socket;
_remoteAddress = _socket.remote_endpoint().address(); //You may call to_string() on it
_remotePort = _socket.remote_endpoint().port();
Related
I'm currently working on a ABAP Push Channel server to WebSocket client connection and I need the IP-address of the client in order to identify whether this client is the one I want to send the message to. In my scenario there could be multiple WebSocket connections.
Now there is the ssi_websocket_table table and the ssi_websocket_table_row row with the the field caller_ip, however this gives me the IP address of the DNS-Server of the network I'm connected to, and I expected the IP address of my local PC since the WebSocket-client is running on this machine.
Is there any other way to get the clients IP address from an active WebSocket connection in ABAP?
P.S. Looking at all the table entries, it shows the correct IP when using a different server configuration, as soon as I know why that's the case I will report back.
As pointed out by vwegert it makes no sense to use the IP to tell the WebSockets apart, I think it would probably be better to use an ID for each WebSocket connection instead.
You could get the IP from the WebSocket server context which gets the IP header apparently from the opening HTTP handshake for the connection:
DATA(lo_context) = i_context. " IF_APC_WSP_SERVER_CONTEXT type
DATA(lo_request) = lo_context->get_initial_request( ).
" initialize G_CONTEXT_ID_FIELD for PCP_SET_CONTEXT_FIELDS
DATA(lv_id) = lo_request->get_header_field( if_http_header_fields_sap=>remote_addr ).
the sample is taken from the SAP standard class CL_APC_WS_EXT_ABAP_ONLINE_COMM, ON_MESSAGE method.
Why does Apache-Commons-Net's FTPClient sometimes make the wrong computation for the port number in the PORT command? This is in active mode. For example FTPClient it could send out
PORT <some>,<ip>,<address>,<here>,235,181 when in fact the port number used is 60340. What's the cause for this wrong computation?
This could happen on version 3.3.
I know ftpClient.enterLocalPassiveMode(); could solve this, but I want to know the part where the active mode doesn't work as expected.
From your comments, I assume you mistake an FTP control connection with a data connection.
I assume that the 60340 is local port of the FTP control connection. When opening data connection, 60341 is assigned (hence the PORT ...,235,181).
Reasoning: In an FTP active mode, the client opens listening port for the expected data connection, which it then reports to the server via PORT command over an existing control connection. If the server cannot connect to the port, no TCP/IP packet can ever come to that port. As you claim that the "two machines still communicate at port 60340", it must be the control connection. There cannot be any communication on port, if the connection failed ("Can't open data connection").
The actual cause of the "Can't open data connection" error is likely that you are behind a firewall, so the server cannot connect back to the client. What is a common nowadays. That's what passive mode is good for.
I want to add support for the PORT command to my FTP server. I'm reading RFC 959, but I can't figure out when it's safe to connect to the FTP client. For example, consider this sequence:
PORT 127,0,0,1,34,34
LIST
Does the FTP client start listening before issuing the PORT command, or after issuing the LIST command? Because if the server attempts to connect to the client immediately after receiving PORT, it might fail because the client might not have started listening yet.
What does the specification say? Can the server connect immediately, or should it wait until after it receives the command that will make use of the data connection?
The server shouldn't connect to the client until it gets a command that requests a data transfer, such as LIST or RETR. See section 7 of RFC 959, which shows a typical sequence of operations (RFC's didn't have the formal MUST/MAY/SHOULD specifications in those early days).
However, since the port used in the PORT command is typically an ephemeral port, the client needs to open a socket to get the OS to assign a port number. This implies that by the time the PORT command is sent, the port would have to be open. However, it's possible that it might not yet have called listen().
Can you please tell me specifically what kind of data flows through which port during an FTP connection?
To be specific, I'd like to know whether contents of the directory and the server response codes flow through port 20.
FTP uses two types of connections: (1) the control connection (default port 21), which is used to send commands to the server and receive status codes back, and (2) the data connection (default port 20), which is used to transfer the content requested from the server: the content of a file or a directory listing, for example. I recommend to use a network protocol analyzer to see it with your own eyes. FTP specification RFC959 is written in an easily understandable manner, don't afraid to have a look at it.
In order to receive datagrams through an UDP connection I have created an object of type UDPClient.
receivedNotificationSock = new UdpClient();
However once done and on using the receive method:
receivedHostNameBuffer=receivedNotificationSock.Receive(ref receivedNotificationIP);
I am getting an exception saying that I must call the bind method.
But there is no bind method in the UDPClient class.
Could You guys please provide me with the code if possible as to what should be done to overcome this exception.
You need I think to know some more about sockets.
All sockets possess a port number. First, you create a socket - which is almost useless on its own. It just floats there. But then you bind it - you assign it a port number. Now it's useful - now you can send and receive data on it.
Remember, all UDP communications are defined by the quad data set of the IP and port of the source and the IP and port of the destination. A freshly created socket doesn't have an IP address or port; binding gives it an IP address and port.
Unfortunately, I'm not a C# programmer, so I can't properly answer your question. But at least you know why it's important.
Pass the port number into the constructor of your UDP client.
receivedNotificationSock = new UdpClient(21000);
You may need to change firewall settings to allow the bind, though a popup window normally opens when you first run this on your dev machine.
For Socket proramming you need to know the sequence of syscalls you need to do on client side and on the server side.
If you are writting a client :
you open a socket with a socket call.
you then connect to the server port with a connect call
once connect is successful
then you send the request to the server using either a send or sendto or a write
which results in reception of data that you can read using a receive or read
On Server Side
you create a socket
bind it to a port
start listening on the socket for incoming connections from various clients using a listen.
There is a non blocking way of listening for connections as well with a select syscall.
Once the you establish a connection you can essentially read the request and start processing it.
Here's an example in C# that may be useful to you.
http://www.developerfusion.com/article/3918/socket-programming-in-c-part-1/