In the future, I will not have an initial TCP 1/0 packet (clue) to process. So I have no way to decide if my forked/spawned process should SSL_connect or SSL_accept.
For example, I cannot see how this can be done with Apple's network framework (at least not yet). It appears to be so high level as to not allow me to process a TCP packet within a TLS style connection. I realize that this is not an openssl issue. And I do have things working today with Apples security framework and openssl (with that extra TCP packet clue in place). I am more familiar with openssl and I'm trying to code everything there first. Also my entire application runs on linux so I am able to test all the combinations easily from there. And I'll need it to work with Apple's networking in the future as their security APIs go away. Thank you for bearing with me so far! On Fri, Nov 15, 2019 at 4:01 PM Phil Neumiller <pneumil...@directstream.com> wrote: > Yes, so you accept thread needs to either fork() or spawn another thread to > process the packet and go back into the accept loop for another connection. > > > > ----- > Phillip Neumiller > Platform Engineering > Directstream, LLC > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > -- This message is NOT encrypted -------------------------------- Mr. Kristen J. Webb Chief Technology Officer Teradactyl LLC. 2450 Baylor Dr. S.E. Albuquerque, New Mexico 87106 Phone: 1-505-338-6000 Email: kw...@teradactyl.com Web: http://www.teradactyl.com Providers of Scalable Backup Solutions for Unique Data Environments -------------------------------- NOTICE TO RECIPIENTS: Any information contained in or attached to this message is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this transmittal, you are hereby notified that you received this transmittal in error, and we request that you please delete and destroy all copies and attachments in your possession, notify the sender that you have received this communication in error, and note that any review or dissemination of, or the taking of any action in reliance on, this communication is expressly prohibited. Regular internet e-mail transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate, and it should not be relied upon as such. If you prefer to communicate with Teradactyl LLC. using secure (i.e., encrypted and/or digitally signed) e-mail transmission, please notify the sender. Otherwise, you will be deemed to have consented to communicate with Teradactyl via regular internet e-mail transmission. Please note that Teradactyl reserves the right to intercept, monitor, and retain all e-mail messages (including secure e-mail messages) sent to or from its systems as permitted by applicable law