does OkHttp3 support the following case:
x.x.x.x myapp.com
y.y.y.y myapp.com
we have two IPs for one hostname, looks like OkHttpClient always retry the first IP address instead of trying another available IP address.
does retryOnConnectionFailure(true) support this? from the doc, by default it should support this?
Configure this client to retry or not when a connectivity problem is encountered. By default, this client silently recovers from the following problems:
Unreachable IP addresses. If the URL’s host has multiple IP
addresses, failure to reach any individual IP address doesn’t fail
the overall request. This can increase availability of multi-homed
services.
Stale pooled connections. The ConnectionPool reuses sockets to
decrease request latency, but these connections will occasionally
time out.
Unreachable proxy servers. A ProxySelector can be used to attempt
multiple proxy servers in sequence, eventually falling back to a
direct connection.
Set this to false to avoid retrying requests when doing so is
destructive. In this case the calling application should do its own
recovery of connectivity failures.
OkHttp will try both in sequence.
Related
As I understand, the max number of TCP connections to a server from a single client IP Address is ~64k connections.
However, what I am not clear about is max number of connections that a server can handle, behind a single load balancer considering that the connections terminate on the Load balancer. Is it ~64k only because there is only one IP from which the server can receive requests?
Indeed, upstream server can handle only 64k connections from the same client due to limitation of ephemeral port range at client side.
But you can assign several IP addresses to the same private interface of your load balancer and force server to use them in a round-robin fashion.
You can define several networks on the same interface of load balancer, for example:
192.168.1.1,
192.168.2.1,
192.168.3.1
And define corresponding extra IP addresses at upstream server:
192.168.1.2,
192.168.2.2,
192.168.3.2 .
With following upstream configuration load balancer will pass requests to the same upstream server while using different IP addresses:
upstream ipproxy {
server 192.168.1.2:some-port;
server 192.168.2.2:some-port;
server 192.168.3.2:some-port;
}
Load balancer will be forced to use different IP addresses thus allowing you to bypass 64k connection limitation and achieve 192k connections.
When the No. of threads are 500 then following error is showing
failed: Connection timed out: connect, My IP is blocking due to multiple hits,
How can I provide 500 users load and My IP should not be blocked.
Well, you need to contact your ISP support and inform them that you're going to use your IP address for some performance testing and ask them to whitelist your IP in their DSoS attack protection software. If your ISP doesn't support this form of usage of your Internet channel - consider changing it or using a cloud VM service provider like Amazon EC2 or Microsoft Azure)
If might also be the case your system under test doesn't allow multiple connections from a single IP address due to aforementioned DDoS attack prevention mechanism on web server level, if this is the case you can use IP Spoofing technique in order to mimic various different IP addresses (not that the IPs or IP aliases must be present in the operating system). The IP address can be configured in the "Source address" section of the HTTP Request sampler
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.
I have a ruby server based on TCPSocket (non-HTTP).
I have 2 different domains, both pointing with an A-Record to my servers IP Address (the same one). So, there are clients connecting to one of those domains.
Is it possible to tell which domain a client was connecting to?
I saw that this is possible in other protocols, but I'm not sure if this is based on manually added headers or really extracted from the basic tcp/ip connection. E.g. in PHP there is $_SERVER["HTTP_HOST"] which shows to which domain a client was connecting.
At the TCP socket level, the only things that are known are the source and destination IP addresses (and ports) of the connection. How the IP address was resolved via DNS is not possible to know at this layer. Even though HTTP works on top of TCP, HTTP servers have to look at the HTTP headers from the client to know which domain they are making a request to. (That's how the HTTP_HOST value gets filled in.)
One possible solution is to configure your server to have an additional IP address. This can be by assigning an additional IP address to the NIC or adding an additional NIC. Then have each domain use a different IP address. Otherwise, this is not possible and you may want to consider your application protocol on top of TCP to convey this information.
I'm using BOOST-ASIO for a simple echo client-server (there is a separate link for the client and server). When I try to run the server I use this async_tcp_echo_server 4000. For the client I use blocking_tcp_echo_client #.#.#.# 4000 (with #.#.#.# as the ip address). I'm on XP-SP3 with my computer connected to my wireless dsl modem using a usb card. After a few seconds on the client side I get this error:
Exception: connect: A connection attempt failed because the connected party did
not properly respond after a period of time, or established connection failed be
cause connected host has failed to respond
Any ideas what it could be? I turned off my firewall including the windows firewall and still I get no response. Could my port be in the incorrect range? Do I need to include a computer name to specify the machine on the network( there are other machines on the network sometimes active)? I did try running this on another computer directly connected to the dsl modem and same issue. I did ping my address and that did work for 4/4 packets.
It could be a variety of issues. Thus, it can be worthwhile to use lower level networking tools, such as netcat to serve a port on the server, and try connecting with netcat from the client side. This can help simplify the problem by removing any potential problems introduced by an application's network programming code. If the problem is identified as being a network issue, then there are a few things to check:
Verify firewall exceptions on the server.
Verify firewall exceptions in the server's network gateway.
If the server and client are on different networks, with the client trying to connect to the server's external IP, then verify that the server's gateway knows what traffic to route to the server. This may require setting up rules, such as port forwarding, in the routing device.
If the server and client are on the same network, but the client is trying to connect to the server through the network's external IP, then verify that the gateway supports looping back internal traffic destined to the external IP.
Use a network analyzer tool, such as Wireshark, to verify that the time to live field in the packets is high enough that it will not be discarded.
you could try
$ telnet server-ip 4000
from your client and see if it is possible to establish the tcp connection.