How do TREP API's behave when the DNS Server returns a list of IP Addresses?
How do TREP API's behave when the DNS Server returns a list of IP Addresses in response to a DNS lookup? Does it treat the list as a "Server List" or does it just take the first IP Address in the list.
So even though the DNS server is returning multiple IP Addresses, only the first IP Address is used. I assume this means that those IP addresses are NOT treated as a server list.
Thanks for all your replies.
Yes - this is correct. The API only uses the first address returned by DNS.
Hi @ron.bove.1
Reading between the lines, I am guessing that what you meant to ask is 'How do the TREP APIs handle a list of servers in the 'serverList' parameter?
If this is your question, then:
RFA (Java, C++ and .NET) has a parameter 'serverSelectionOrder' which If set to True, servers in the serverList are chosen randomly instead of from left-to-right. This also affects the serverList of any Warm Standby Lists used by the connection.
If/when a connection to the selected server fails, RFA will try and failover to another server in serverList.
The question (we had a conversation about this) comes from a client using round-robin DNS for failover and load balancing of ADS clients. [ Don't judge, just answer ] If a server hostname lookup returns a list of IPs from a round-robin DNS entry for a single (or only) server name in the serverList parameter, will RFA
- expand those IPs into a new longer serverList
- pick one, use it once, and do the name to address mapping again upon disconnect
- pick one IP and use it forever
- none of the above ?
What about EMA?
After resolving name, the list of IP addresses are kept in the DNS cache on the local machine. You can use ipconfig /displaydns on Windows to display the DNS cache. Then, it will use the information in the cache for the subsequent name resolving. TREP APIs use the first returned entry for the connection which is the first entry in the cache.
trep.rdc.reuters.com ---------------------------------------- Record Name . . . . . : trep.rdc.reuters.com Record Type . . . . . : 1 Time To Live . . . . : 3571 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 192.168.27.41 Record Name . . . . . : trep.rdc.reuters.com Record Type . . . . . : 1 Time To Live . . . . : 3571 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 192.168.27.11
For example, with the above cache, TREP APIs will use 192.168.27.41 for the connection and re-connection for trep.rdc.reuters.com.
However, if I flush the cache (ipconfig /flushdns), the first entry in the cache can be changed in round robin after the next name resolving.
trep.rdc.reuters.com
----------------------------------------
Record Name . . . . . : trep.rdc.reuters.com
Record Type . . . . . : 1
Time To Live . . . . : 3598
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 192.168.27.11
Record Name . . . . . : trep.rdc.reuters.com
Record Type . . . . . : 1
Time To Live . . . . : 3598
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 192.168.27.41
After flushing, the first entry in the DNS cache has been changed to 192.168.27.11. TREP APIs will use 192.168.27.11 for the connection for trep.rdc.reuters.com.
Therefore, if you disable the DNS cache (net stop dnscache), the first resolved entry can be changed in round robin so TREP APIs can use different IPs for the subsequent connections.
In my opinion, a serverList parameter and DNS are used in the different context/level.
Any values defined in serverList, are processed when TREP's APIs read configuration settings at the beginning when you start the application. This is the scope that the application can handle.
After that, when TREP's APIs make a connection, this take is handled by lower levels which should be standard libraries, a runtime itself (e.g. Java Runtime; JRE), and OS by receiving a hostname from the higher level (i.e. the application and TREP's APIs).
Therefore, I don't think that any return values from DNS lookup will be seen by TREP's APIs level.
All of the APIs (RFA, EMA, ETA/UPA) across languages will use the hostname lookup call that is appropriate for language and platform (getAddrInfo, gethostbyname, etc).There is nothing fancy going on – it will essentially connect to whatever address the name provided by the user is resolved to.If the DNS server is changing that address behind the scenes, it may result in subsequent reconnection attempts to the same hostname going to different underlying IP address as the API requeries the host to connect to upon reconnection (if DNS cache flushes, etc).
ServerList/ChannelSet parameters allow users to provide a list of hostnames that the API will iterate through upon connection loss. As it iterates the server list, it will use the underlying system calls to resolve the IP for the host in the list it will try next. Each host in the list will essentially behave as described in the first paragraph.
Hi @brian.sandri,
Hostname lookup calls (getAddrInfo, gethostbyname, etc) may return a list of IP addresses for a single name to resolve. What Ron wanted to know is if our APIs use these multiples IPs or only the first one. In his answer below Ron is assuming that only the first IP is used. This is also what I understand from your answer, even if you do not say it explicitly. If this assumption is correct, could you please confirm it by commenting Ron’s answer below? We will then tag it as the Best Answer in order to guide other community members who have a similar question.
Thanks again for all your replies,
In a related question, from testing there seems to be a subtle difference in the behavior between SSL and RSSL when it comes to recovery. It appears that with RSSL, if the connection to the first ADS disconnects, the application immediately switches to the second ADS in the Server List and so on. However, for SSL, it appears that the application will first attempt to reconnect to the ADS that it was disconnected from, before moving on to the next ADS in the Server List.
Normally this wouldn't make a difference, but by using DNS Load balancing it changes the behavior.
Is this expected behavior in RFA? Is this application dependent? Should we expect the same behavior in other API’s?
Yes, for SSL connection type, the application will first attempt to reconnect to the ADS that it was disconnected from, before moving on to the next ADS in the Server List. This is a connection recovery logic in SSL API.
However, RSSL API itself doesn't have the connection recovery logic so the behavior depends on the application or the API libraries which build on top of RSSL API.
For example, the ETA Reactor Value-Added library, RFA C++, and EMA C++ will reconnect to the next ADS in the connection list after disconnection.