In Comet/Reverse Ajax/PubSub underlying technology/fundamental is Long polling. So connection is kept open for a minute or so..
And as per my little knowledge about networking and OS, TCP/IP supports only 65535 ports, so my question is how any server can support more then 65535 connections concurrently?
In application I am building, All users are going to connect at same time, and wants live updates from server.. like stock treading realtime updates..
Cheers,
You are correct in that there are 65535 unique port numbers, but a TCP server application allows many clients to connect to the same port on a server. For example, in a web server all clients connect to port 80. Connections are uniquely identified by the 4-tuple (src-address, src-port, dest-address, dest-port).
You will definitely want to read about the so-called C10K problem when designing your implementation.
each connection is attributed as follows:
source ip (could be any)
source port (could be any in range 1024-65535)
destination ip (your server ip)
destination port (specific port your app is running on)
so the number of connections to the server is limited by the number of all possible ips multiplied by the 64000 (roughly). no server can handle that as of yet... :)
Related
Good afternoon, i have 2 PC's, where one is my WAMP server, with MySQL Database and so on. And the other i made a connection to my DB throw MySQL Connector ODBC Driver.
My doubt is if is there a way to block access of this second PC to my Server PC ?
I'm learning about MySQL control management, and i came across with this case, and i couldn't found an answer searching about this by myself.
No, there's no builtin mechanism in MySQL Server that detects that a connection attempt is from a MySQL Connector ODBC Driver, and blocks the connection.
It is possible to block connections to the MySQL Server, by setting up the appropriate user definitions in MySQL Server (entries in the mysql.user table).
In MySQL, a user is identified by a user name together with a host (either a DNS hostname or IP address, depending on whether we've specified skip-name-resolve option.)
If we setup MySQL users with wildcard hostname '%', then we are allowing TCP/IP connections from any host or any IP address.
If we remove user entries with a wildcard hostname, and instead create users with a more specific hostname (or IP address), then connections will be allowed only from the specified host/IP address. With a net effect of blocking connections from other hosts.
This topic is more fully addressed in the MySQL Reference Manual
https://dev.mysql.com/doc/refman/5.7/en/connection-access.html
Also, for TCP/IP connection attempts, a network firewall (for example, Iptables on Linux) can be configured to knock down connections before they are even seen by MySQL Server.
According to this document
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-remote-database-to-optimize-site-performance-with-mysql
To connect from external ip to mysql I have to change to public ip of the server
bind-address = your_database_IP
I put here my public IP server.
So my question is does it lose performance. Does it understand that this ip actually its on ip so it will act like local database? Or it will think it is external ip so goes in internet and comes back again ?
Connection possibilities:
Socket -- the fastest, but only works when client and server are on the same hardware (or, in some cases, the same VM)
TCP/IP on the same hardware, but through the TCP/IP stack, so slightly slower for queries.
Domain name lookup, and other issues dealing with establishing remote (not same machine) connection. This action is done only during connecting. So, it might slow down establishing the connection, but not the queries. Note: the translation from "foo.com" to "1.2.3.4", if needed, is done once, only during the establishment of the connection. An explicit IP address is faster, but less flexible.
Proxy server / load balancer / etc -- these sit between the client and the server, and add some delay (and some benefit) during all queries.
Connection pooling in the client -- some overhead or savings on connecting.
Connection pooling in the server -- some overhead or savings on connecting. (Whether to reuse a process (thread) versus create a new one.)
The beauty of TCP/IP is that you can send a message to any IP address you know; the 'network' will figure out how to get there (anywhere in the world). It may take one route now, another route the next time. So it is "reliable", but inconsistent is speed. It also has a good level of "guaranteed delivery". Once connected, that is what queries do -- send to a known IP address and get replies.
(See the other comments for more info.)
we have mysql-server(5.5.47)that hosted on physical server. It listen external internet interface(with restrict user access), mysql server intensively used from different places(we use different libraries to communicate with mysql). But sometimes whole mysql server(or network) stuck and stop accept connection, and a clients failed with etimedout(connect)/timeout(recv), even direct connection from server to mysql with mysql cli not working(stuck without any response — seems to be try to establish connections).
First thought was that it is related to tcp backlog, so mysql backlog was increased — but this not help at all.
Issue not repeatable, so last time when this issue happened we sniff traffic, and what we get:
http://grab.by/STwq — screenshot
*.*.27.65 — it is client
*.*.20.80 — it is mysql server
From session we can assume that tcp connection established, but server retransmit SYN/ACK to client(from dump we see that server receive ACK, why retransmit ?), but in normal case mysql must generate init packet and send to client, after connection was established.
It is only screen from 1 session, but all other sessions mostly same, SYN -> SYN/ACK -> ACK -> and server retransmit SYN/ACK up to retries_count.
After restart mysql all get normal immediately after restart. So not sure it is related to network or mysql.
Any thoughts would be appropriate.
Thank you!
We need to query and pull data from our client's remote PostgreSQL database and ultimately import it into a table in our MySQL database. Due to security concerns, our client is unwilling to open access via the default port 5432 so we can do this. We have considered possible setting up a PostgreSQL database on our end and trying to connect with that, but we don't know if that will give us any more flexibility.
The question is, is there an alternative port other than 5432 that we can have our client open up so we can access?
Configure PostgreSQL server to accept connections from a specific IP + authentication, without changing default port. This normally should be done even for local connections.
Configure router/firewall to do port forwarding (i.e. firewall:port9999 --> postgresql_server_ip:port5432) + add source_ip as another layer of "security"
I'm running EC2 with MySQL RDS to serve dynamic websites' content.
The server was down due to 'too many connection' error on RDS database.
As it was urgent, I restart database server straight away and the problem gone.
However, I'm unable to see what queries produce those connection (as I didn't run SHOW PROCESS LISTS before reboot RDS).
CloudWatch show 250+ connections during period of issue which is obviously huge distinction from normal operating on other days.
I try to address the issue by see log in RDS, but there is quite a minimal message there.
The error message
2014-05-03 06:10:08 3628 [Warning] IP address '173.244.206.19' has been resolved to the host name '173.244.206.19.static.midphase.com', which resembles IPv4-address itself.
From above, 173.244.206.19 is not in our IP list both public and private. (but connection open to 0.0.0.0 secured with password which I'm going to limit IP remote in security group soon)
Questions
Is 173.244.206.19.static.midphase.com is something to do with RDS by default. I think this is obviously an attack sign but just would like to confirm.
What does 'resembles IPv4-address itself' mean? As this is RDS database server only, why server does need to resolve DNS?
Are there any way to digging into this for further detail (e.g. to see specific query).
I'm going to prevent this by only limit the IP access along with CloudWatch alarm setting for 10+ connections. Anything else I should do.
Thank you for reading through this guys. I'm the only developer in company start-up which take care for all front-end/backend/application/network. Therefore, apology if there are dummy questions out here.
However, your help would be really appreciated and will save a bit of my life writing the report.
You are maybe the target of a DDOS attack or a brute-force password discovery attempt.
I would report this to AWS support - as they can help to mitigate the effect of the attack.
As a best practice, we do not recommend to use 0.0.0.0/0 as source IP address for incoming connection rule in Security Group.
Try to restrict which IP addresses are authorised to connect to your database.
If you are accessing from on prem network, specify only your on-prem address range.
If you're accessing your database from an app server installed on EC2, use the ID of the App Server Security Group (sg-xxxx) as source authorised to connect to your database.