I'm trying to establish TCP connection with PostgreSQL 9.1 server via Microsoft telnet. but When the connection has been establishe I received
Jconnector 3.6 1 ♥
What does it mean? Is it opssible at all to establish such connection manually to communicate the database via TCP?
When a TCP connection to a port is opened, what is listening on the Port sometimes announces itself: in this case, what is listening is Jconnector 3.6.1. The heart-shape is some binary data.
TCP connections tend to be only used by program code, as 'conversations' at that level quite often involve binary data. I don't know what Postgres does, but if you get it to run a select and return the data it will very likely be all binary and quire unreadable by a human.
If you search for what the wire-protocol is for Postgres, you may be able to make it do something via a telnet session, but expect you'd have a lot of difficulty.
Related
Say I have a public server on the Internet, written in C, that is connected to two independent clients. Both clients initiated the connection. One client is (e.g.) an iOS app, the other is a native Windows app.
The purpose of my server is to allow these clients to send text messages to each other. Client 1 sends a message, the server receives it, and then forwards it onto Client 2. The same thing happens in reverse when Client 2 sends a message.
This feels inefficient. What I would really like is for both of these connections to contact the server and then for the server to connect these two clients directly to each other - after which my server can forget both clients as they are responsible for communicating with each other. My server is then free to connect up other clients in the same way.
My question is: is this even possible (with TCP and/or UDP)? Neither client necessarily has a public IP address, which is why they have to initiate the connection. Once the connection is established however, my server knows the connection address of both clients. Is there a way to connect them together? A syscall that can do this sort of thing, perhaps?
No, you can not join two existing TCP connections to one.
There are 2 options:
1) Keep your server in the middle as it already is. It should not be problem, if you don't have thousands of clients under one server.
2) Server could send control messages to clients, and order those open new TCP connection between each other. Server should also make decision which of the two clients must be initiator of the new TCP connection.
Option 2 is problematic, because client may have firewall rule that prevents in coming connection to the wanted port. Also NAT would cause problems.
I have a standard client server situation. Clients connect to the server, and the server manages multiple client connections using select() (or similar). Everything uses the POSIX system level networking API.
Sometimes the server needs to close a connection. I want the server to be able to send a message to the client before closing the socket, to inform the client about the reason for the connection being closed.
What is the best way to do that?
The straight forward approach would be to simply have the server write the message and then close (close()), but I imagine that this is problematic, as the client might then get a write error due to the connection having been closed by the server, before the client gets a chance to read the final message written by the server.
Is that the case, or can I be sure that the client does not get a write error until after it has read everything?
Is there a better way to do it?
If possible, I would prefer a solution that is based only on the POSIX specification.
The server should:
Write the message.
Shut down the write side of the connection with a call to shutdown.
Continue reading from the connection until it detects a normal shutdown so that all data sent by the client is read.
I have a C service application that use tcp socket for connection to a server. The server sends data now and then. Also my application sends a hearbeat every 15 seconds. But sometimes it disconnects while server seems to think the connection is live. Now if I try to reconnect the server refuses as it holds only one connection for the client at a time.
What is the best way to hold a persistent tcp connection?
Edit:
The server usually disconnects after 2 min without heartbeat. So after I find my connection is closed it takes 2min for me to successfully reconnect. I want to minimize this time.
The simplest fix is probably for the server to allow a new connection to replace an old connection rather than rejecting it. That would still keep only one connection to each client at a time.
I have the following setup:
2 Ubuntu machines (server and client)
on the "server" I'm running this to echo all the data received back to the sender (the client):
ncat -e /bin/cat -v -l 12345
on the client I have simple application which just connects to the remote socket: socket() -> setsockopt() -> connect()
So... my question is: Is it possible to check if there are other applications already connected to the socket from the client application? I want only one process connected to the socket at any given time and I want to check this from the client application. Is this possible? After 3h googling I couldn't find anything relevant :(
(sorry, no experience with network programming)
No, a client is not able to see how many other clients are connected to a server.
To be able to retrieve this information an application specific protocol needs to be used on client and server.
Anyhow there is this one special case: If the client knows that a maximum of N clients can connect to the server, and it's own try to connect is refused it could assume that N clients are connected to the server already.
To set the maximum number of connections ncat handles in parallel use it's option -m/--max-conns. Verbatim form man ncat:
-m numconns, --max-conns numconns (Specify max number of connections) .
The maximum number of simultaneous connections accepted for an Ncat instance. 100 is the default.
Run:
netstat -an | grep <your server port port number>
on your client machine to see any existing TCP connections.
Can you not close the listening socket on the server after you've accepted one client? If there's no listening socket no more clients will be able to connect. Once you've dropped your one client, you can then open the listening socket again, ready for one more. That way the client will see a "failure" to connect if the server is busy, or will succeed normally otherwise.
The down side of this approach is that the client won't be able to determine exactly why it can't connect, it could be because the client is busy (has its one client) or it could be because of other issues. Does this matter?
Hi Socket Programming experts,
I am writing a proxy server on Linux for SQL server 2005/2008 running on Windows.
The proxy is coded using bsd sockets and in C, and it is working fine with a problem described below.
When I use a database client (written in JAVA, and running on a Linux box) to fire queries (with a concurrency of 100 or more) directly to the Database server, not experiencing connection resets. But through my proxy I am experiencing many connection resets.
Digging deeper I came to know that connection from 'DB client' to 'Proxy' always succeeds
but when the 'Proxy' tries to connect to the DB server the connection fails, due to the SYN packet getting RST,ACK.
That was to give some background. The question is :
Why does sometimes SYN receives RST,ACK?
DB client(linux) to Server(windows) ----> Works fine
DB client(linux) to Proxy(Linux) to Server(windows) -----> problematic
I am aware that this can happen in "connection refused" case but this definitely is not that one. SYN flooding might be another scenario, but that does not explain fine behavior while firing to Server directly.
I am suspecting some socket option setting may be required, that the client does before connecting and my proxy does not. Please put some light on this. Any help (links or pointers) is most appreciated.
Additional info:
Wrote a C client that does concurrent connections, which takes concurrency as an argument. Here are my observations:
-> At 5000 concurrency and above, some connects failed with 'connection refused'.
-> Below 2000, it works fine.
But the actual problem is observed even at a concurrency of 100 or more.
Note: The problem is time dependent sometimes it never comes at all and sometimes it is very frequent and DB client (directly to server) works fine at all times .
SQL Server needs worker threads to accept incoming connections. If your server is worker starved (which can be easily diagnosed by a high number of entries in sys.dm_os_tasks in PENDING state) then attempting to open new connection will fail. So likely what I suspect it happens is that you're pushing to the server more workload that it can handle. You need to optimize the workload or get a beefier server.
Clients like Java client make effective use of connection pooling and, even under a high load, do not need to open new connection hence you do not see this problem, instead you see only delays in requests completion.
A listening socket keeps queue of established connections and connections in establishment process (e.g. SYN got, SYNACK replied, but not ACK from client yet). If a established queue overflows, IP stack reaction differs on OS. The most traditional approach was to ignore newcoming SYNs, waiting when userland accept()s and frees a slot in the queue. With SYN flooding attacks in mid-90s, the new method was invented named "SYN cookies" which drops need for establishment queue totally, in cost of need to support special TCP option.
OTOH I have heard that Windows stacks change their behavior - under some conditions, the reaction to queue overflow is RST response. In earlier stacks (e.g. Win95) this was the main response and client side was correspondingly changed to ignore RST response to SYN:(
That's why I guess that some proxy host feature triggers RST in Windows stack.
Another guess is that DB server closes listening socket at all under some condition (e.g. detected overload peak) which appears only with proxy.
When the SYN receives the RST response, it should not be the problem of SQL-SERVER.
Because the application is able to accept the socket only after the tcp handshake finished.
Is there any device between the Proxy and the SQL-Server machines?
Try to make sure that the RST response come from sql-server machine.
You connection count is far from SYN-FLOOD, I think.