Using domain name instead of IP address for BlueBox
Posted: 27 Jun 2014, 08:35
Using the latest (1.1.2) SFS2X C++, we are able to connect using TCP and UDP by configuring a DNS resolvable hostname. This all seems to work really well as the hostname is properly resolved to an IP address.
We tried to test on BlueBox today and could not get it to connect. After spending a lot of time stepping/debugging through the SFS2X C++ source code, we found that BlueBox connectivity attempts to use the host/IP address directly without attempting to first resolve a potential DNS to IP address as it does when connecting via TCP. It attempts to use the host name directly as an IP address which will cause an exception to be thrown in this code:
After some thought - we can see why doing a DNS lookup for each unique HTTP request to the server would be a bit excessive. However, it would be a good idea to do the IP address resolution and store it as an "endpoint address" so that the DNS lookup does not need to happen for each poll/message from the server. Forcing the use of an IP address is really bad for portability. What if I change servers, or data centers and get assigned a different permanent IP address? I can migrate my SFS2X licenses to new servers and that all works fine. However, if I have App Store/Google Play app binaries in the wild with the IP address to SFS2X hard coded, that could be a very big potential problem.
Until this is fixed, we'll attempt to fix on our own. It shouldn't be too hard with the only downside being that we're basically modifying SFS2X C++ client code and will need to maintain that on our own until you guys release a fix for this. If it helps, we'd be more than happy to share our fix in this thread/forum and the team can choose to take our fix and merge into the next SFS2X C++ release or not.
We tried to test on BlueBox today and could not get it to connect. After spending a lot of time stepping/debugging through the SFS2X C++ source code, we found that BlueBox connectivity attempts to use the host/IP address directly without attempting to first resolve a potential DNS to IP address as it does when connecting via TCP. It attempts to use the host name directly as an IP address which will cause an exception to be thrown in this code:
Code: Select all
void SFSWebClient::UploadValuesAsync (boost::shared_ptr<string> uriHost, unsigned short int uriPort, boost::shared_ptr<string> paramName, boost::shared_ptr<string> encodedData)
{
boost::shared_ptr<TCPClient> client = boost::shared_ptr<TCPClient>();
try {
client = boost::shared_ptr<TCPClient>(new TCPClient(boostIoService));
boost::shared_ptr<IPAddress> address (new IPAddress(IPAddress::IPADDRESSTYPE_IPV4, *uriHost));
client->SynchConnect(address, uriPort);
}
catch (exception e) {
boost::shared_ptr<string> messageException (new string(e.what()));
boost::shared_ptr<string> message (new string("Http error creating http connection: " + (*messageException)));
OnHttpResponse()->Invoke(true, message);
try {
client->Shutdown();
}
catch (exception e) {
boost::shared_ptr<string> messageException (new string(e.what()));
boost::shared_ptr<string> message (new string("Error during http scocket shutdown: " + (*messageException)));
OnHttpResponse()->Invoke(true, message);
}
return;
}After some thought - we can see why doing a DNS lookup for each unique HTTP request to the server would be a bit excessive. However, it would be a good idea to do the IP address resolution and store it as an "endpoint address" so that the DNS lookup does not need to happen for each poll/message from the server. Forcing the use of an IP address is really bad for portability. What if I change servers, or data centers and get assigned a different permanent IP address? I can migrate my SFS2X licenses to new servers and that all works fine. However, if I have App Store/Google Play app binaries in the wild with the IP address to SFS2X hard coded, that could be a very big potential problem.
Until this is fixed, we'll attempt to fix on our own. It shouldn't be too hard with the only downside being that we're basically modifying SFS2X C++ client code and will need to maintain that on our own until you guys release a fix for this. If it helps, we'd be more than happy to share our fix in this thread/forum and the team can choose to take our fix and merge into the next SFS2X C++ release or not.