When I am calling SSL_write() from client's end and if Server has already terminated the SSL Connection, First SSL_Write() is successful (returns correct number of bytes). However as soon as I perform second SSL_Write(), Client Process/Application terminates unexpectedly. Is there anyway to find out that Server has closed the SSL connection and Client should not perform any further Writes? To close SSL Connection on Server side, I am calling following syscalls:
close(server_fd);
SSL_CTX_free(ctx);
Related
From here:
When SQL Server clients request SQL Server resources, the client network library sends a UDP message to the server using port 1434. SQL Server Browser responds with the TCP/IP port or named pipe of the requested instance.
Apparently when UDL or SSMS used for connecting remotely to SQL Server instance name, the query for resolving the instance name's port number store's somewhere in client machine.
I tested this by two client machines. When the 1434 UDP port was open first machine could connect to SQL Server instance name. Then I closed the port and tried again with that machine. The first client still could connect without the port being open. Then I tried with second machine but it couldn't connect.
I just wondering how and where this caching takes place?
Client APIs like SqlClient use connection pooling by default to avoid the overhead of name resolution, physical network connection, and authentication every time a connection is opened. When the initial connection is closed, the connection is added to a connection pool where it can be reused the next time another connection with the same attributes is opened. The client API in that case simply retrieves and unused connection from the pool avoiding the significant overhead of establishing the physical connection.
With a named instance, connection pooling also avoids the need to query the SQL Server Browser service every time a connection is opened so this explains your observations. I suspect if you exit and re-launch the application after blocking UDP port 1434, the SQL connection for the named instance will fail due to the failed SQL Server Browser data gram query during the initial connection open.
I have a client process running in windows (win 7/win 2008 server). The task is to enable keepalive for one of the socket it opened to get connected with a server.
To make this connection i'm using windows API (connection to MSSQL server), from which i was unable to retrieve the socket fd it created.
1) What is the way to retrieve all the socket fds opened by a windows process (non python method, as the binary is a C++ based)
2) Is there any way to retrieve socket fd from the handle returned by the windows API SQLAllocHandle or SQLDriverConnect
Thanks
You can't (AFAIK) and shouldn't (not supported) try to modify this on the client. SQL Server has a server-side configuration setting that controls this:
Keep Alive
This parameter (in milliseconds) controls how often TCP attempts to verify that an idle connection is still intact by sending a KEEPALIVE packet. The default is 30000 milliseconds.
https://technet.microsoft.com/en-us/library/ms190771(v=sql.105).aspx
I have got step by step information on how to enable/set/modify the keep alive option on MSSQL Server side. But, how to do the same while using ODBC client to connect with MSSQL Server? This is mainly used to close the socket on client side and start reconnecting.
I came across an option called "Connect Timeout
-or-
Connection Timeout", in connection string, which disconnects if there is no connection after that timeout. But i hope TCP keep alive does more than this.
Couple of options would do for me,
1) Is there a keepalive option that could be added in connection string (similar to postgres)?
2) How to get the client socket fd, which connects with the MSSQL Server, (without using OS commands) so that, i could use setsockopt API and enable keep alive
I'm implementing my own TCP server. So far I can make a connection, that works fine, I can connect to any client. However when I want to send or receive messages from the client it goes wrong. The following is a snippet of the last part of my server, where I want to send the message WeLcOmE to my client (I'm using C programming language & Linux as the OS):
// Accept a connection request
int clientAddress = sizeof(client_address);
int new_socket = accept(door_socket, (struct sockaddr *) &client_address,
&clientAddress);
if (new_socket < 0)
perror("ERROR on accept");
// Receive data from socket, send data to socket
char buff[8] = "WeLcOmE";
send(new_socket, buff, sizeof(buff), 0);
// Close socket
close(new_socket);
close(door_socket);
return 0;
Running my server with a Filezilla Client this is what I get:
Status: Resolving address of ubuntu
Status: Connecting to 127.0.1.1:3471...
Status: Connection established, waiting for welcome message...
Response: WeLcOmE
Error: Could not connect to server
Status: Waiting to retry...
Status: Resolving address of ubuntu
Status: Connecting to 127.0.1.1:3471...
Status: Connection attempt failed with "ECONNREFUSED - Connection
refused by server".
Error: Could not connect to server
Running my server with the ftp Linux built-in client I get:
ftp> WeLcOmE421 service not available remote server has closed connection
I don't understand why is this happening. Any help is appreciated.
As you have yourself stated, you have implemented a "TCP" server. All the server does is that it sends the "WeLcOmE" string to any TCP client that connects to the server.
If you connect with an FTP client to the server, the client gets the "WeLcOmE" string, and as that does not conform to the FTP protocol specification, the client errors.
The same would happen, if you connect with any other client that uses a specific protocol, e.g. a web browser [HTTP], a terminal client [SSH or Telnet], etc.
Now the question is, what you are trying to achieve:
Either you want to implement an FTP server. For that you need to read the FTP specification and implement your server according to it. That's an immense task and in general you do not want to do that. You better take an existing implementation. Either an FTP server library and build your custom FTP server on it. Or take a complete open source FTP server and customize it to your needs.
Or you just play with your toy TCP server and you want to test it. For that use any TCP client that can work in "raw" mode by reading from the socket and just displaying what it gets, without trying to interpret the data in any way. You can use PuTTY in a "raw" connection mode. See section Making raw TCP connections in PuTTY documentation.
I am new to socket programming.Please provide me some techniques to run the server socket infinitely even if I close the client socket using close(clientfd) in C programming (the server has to wait in accept()for the next client connection even if the current connection is closed ). Also kindly help me how the close() in client side affects the socket in server side.