[
https://issues.apache.org/jira/browse/THRIFT-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Pye updated THRIFT-151:
---------------------------
Ping,
Happy new year back at ya!
Here are a few notes after playing with your patch for a bit.
* Code almost compiles fine for me on a Macintosh.
To compile, I had to adjust the header prefix paths, removing the
/thrift/lib/cpp/src prefix.
Also, the type ulong is u_long on a Mac, which caused some problems.
* There also a few warnings which seem easily fixed and I think are again Mac
specific:
src/transport/TFileTransport.cpp: In member function 'bool
facebook::thrift::transport::TFileTransport::isEventCorrupted()':
src/transport/TFileTransport.cpp:620: warning: format '%ld' expects type 'long
int', but argument 7 has type 'long long int'
src/transport/TFileTransport.cpp: In member function 'void
facebook::thrift::transport::TFileTransport::performRecovery()':
src/transport/TFileTransport.cpp:661: warning: format '%lu' expects type 'long
unsigned int', but argument 3 has type 'long long int'
* TSSLServer.cpp: static ulong callbackThreadID()
The implementation of this method seems very pthread specific and I don't think
will work for Windows. How is multi-threading
This method seems very pthread specific and I don't think will work for Windows
or other non-POSIX places. Is it the case that thrift requires pthreads though
anyway?
* lib/cpp/Makefile.am
For the TSSLSocket.o file to be generated, TSSLSocket.cpp and
TSSLSocket.h should be added to the list of source files.
Also, a reference to -lssl might need to be added to /Makefile.am so
that the build system checks for its presence.
* SSL v BIO
Is there a reason you are using the SSL_ functions, as opposed to the
BIO_ ones?
* When I try running the code hacked into the cpp tutorial, it fails with the
following error:
terminate called after throwing an instance of
'facebook::thrift::transport::TTransportException'
what(): SSL_CTX_new() returns NULL
I'm too lazy now to dig into this, but if I have some free-time, I'll try to
see if this is my fault or the libs.
In general, the ssl implementation seems complicated, and a small usage
example would be very helpful.
* Client and Server certificates:
I might be missing this, but it looks like the default in TSSLSocket is for
only the server to send a cert. to the client, and not for the client
to identify itself to the server. I argue that in Thrift the
default should be for both ends to identify themselves.
* Architecturally, I like the way that TSSLAcceptSocket inherits from
TServerSocket.
* Keeping both the SocketServer and SocketClient classes in the same file is a
bit confusing for me.
* Handling encrypted keys is a good feature to have.
* It looks like the basic MT synchronization functions are present. What about
added the additional ones, dyn_create_function, dyn_lock_function and
dyn_destroy_function for better performance?
Ian
> TSSLServerSocket and TSSLSocket implementation
> ----------------------------------------------
>
> Key: THRIFT-151
> URL: https://issues.apache.org/jira/browse/THRIFT-151
> Project: Thrift
> Issue Type: Improvement
> Components: Library (C++)
> Reporter: Ian Pye
> Attachments: ssl-pingli.patch, ssl.patch
>
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> SSL Connections w/ autogenerated self signed x509 certs seem to be the state
> of the art for rpc layers.
> It would be good if there was a C++ implementation of TSocket and
> TServerSocket classes.
> This is similar to the Java issue Thrift 106.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
