只要是用到了OpenSSL，总会碰到让人心塞的事。这次是SSL_get_fd。我用一种很简单的方式创建了一个SSL对象，直接在这个对象上进行SSL的accept：bio=BIO_new(BIO_s_a
.
只要是用到了OpenSSL，总会碰到让人心塞的事。
这次是SSL_get_fd。我用一种很简单的方式创建了一个SSL对象，直接在这个对象上进行SSL的accept：
bio = BIO_new(BIO_s_accept());BIO_set_accept_port(bio, "1234");BIO_do_accept(bio);SSL_set_bio(ssl, bio, bio);SSL_accept(ssl);
这样就不必折腾讨厌的sockaddr了。后来我想在和这个SSL对象关联的底层socket上执行setsockopt，想当然的使用了SSL_get_fd/BIO_get_fd这个非常自明的API。到此为止非常棒。接下来就不爽了，我发现setsockiot最终操作的那个描述符是listnen套接字，而不是accept返回的那个套接字。这似乎在API层面上十分合理，毕竟bio的参数就是一个BIO_s_accept，而和它关联的就是一个listen套接字。想要正确的得到accept返回的读写socket描述符，你得这么写：
BIO_get_fd(BIO_next(bio), &sd);
问题是，你必须知道这个BIO stack是如何排列的才能写出上面的代码，做到如此最好的办法就是看OpenSSL的源代码。
BIO的API设计就一定要设计成get/set_fd吗？BIO就一定要和一个fd相关吗？memory类型的BIO如果get fd的话，会返回怎么的错误吗呢？既然BIO构成了一个叠加的IO stack，那么也许之有最下面的那个才会和一个UNIX fd相关联，那为何不直接返回最下面那个呢？
