[ 
https://issues.apache.org/jira/browse/THRIFT-5327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283819#comment-17283819
 ] 

Paolo Elefante commented on THRIFT-5327:
----------------------------------------

Hi guys,
I see the problem in the C++ method TSocket::getPeerHost().

In details, getPeerHost invokes the API getnameinfo that unfortunately, in case 
of DNS misconfigurations, hangs for several seconds and returns an error that 
is ignored. I thing this part of code of getPeerHost() can be handled 
differently:
{code:java}
    char clienthost[NI_MAXHOST];
    char clientservice[NI_MAXSERV];

    getnameinfo((sockaddr*)addrPtr,
                addrLen,
                clienthost,
                sizeof(clienthost),
                clientservice,
                sizeof(clientservice),
                0);

    peerHost_ = clienthost;
{code}

In case getnameinfo returns any error peerHost_ cannot be set.
The class TSSLSocket is also affected by this behavior.

BR, Paolo

> ServerHello is sent with a delay from thrift
> --------------------------------------------
>
>                 Key: THRIFT-5327
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5327
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.13.0
>         Environment: C++ Application running on linux x86_64
>            Reporter: A.Hari Venkata Ramana
>            Priority: Major
>
> I have a C++ environment which uses thrift for server. Server is of type 
> TThreadPoolServer with TBufferedTransportFactory as transport and  
> TBinaryProtocolFactory as protocol. Clients get connected to this server and 
> this happens via TLS.  We are using thrift server with version 0.13.0 on the 
> server end. 
>  
> In one of the environments where a client using thrift (version 0.10.0), the 
> client Hello is sent as part of initial TLS negotiation. We have observed 
> that the server Hello is sent after around 25-30 seconds after the client 
> Hello is received by the server. 
>  
> In these cases where delay is observed on server end we are printing the 
> client origin details, ie., the server ip of client and the port from which 
> it is connecting to the server.
>  
> functionXXX(const ::apache::thrift::TConnectionInfo& connInfo){
>     std::string origin = connInfo.input->getInputTransport()->*getOrigin*();
>     printf("CONNECTED: %s\n", origin.c_str() );
>  
>    .......}
> In cases where the ServerHello is delayed from thrift, we see the junk 
> characters in prints from the above code as shown below:
>  
> { Info = "CONNECTED:  ����:52089"} 
>  
> { Info = "CONNECTED: ����:52465"}
> { Info = "CONNECTED: ����:55027"} 
> { Info = "CONNECTED: ����:59066"} 
> In cases where the IP address of the client is shown as normal characters (as 
> shown below) we dont see any delay in the serverHello sent from the thrift 
> server and it just takes few milli seconds to send the serverHello back to 
> client.
>  
>  \{ Info = "CONNECTED: 172.30.1.41:46573"}
>  
> Looking at the change history we see the following change done in thrift 
> 0.13.0:
>  
> - [THRIFT-4762](https://issues.apache.org/jira/browse/THRIFT-4762) - cpp: 
> TTransport::getOrigin() is now const
>  
> Could this be the cause of the delay from the thrift server in sending the 
> Server Hello back to clients as part of TLS negotiation?
>  
> Any pointers here would be very useful.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to