<div dir="ltr">Hi Phil,<div>Thanks for such a fast response!  I am doing the polling today.</div><div><br><div>I believe I left something very important out of my original question.</div><div>I only have 1 well known port to accept all of my connections.</div><div><br></div><div>TLS_client_app -> service on portA (needs to be a TLS_server)</div><div>TLS_server_app -> service on portA (needs to be a TLS_client)</div><div><br></div><div>The problem is that when the service accept()'s the connection it does</div><div>not know what type of app made the connection so it cannot decide</div><div>if it should act as the TLS client or server (unless I send a 1/0 hint</div><div>over TCP first).</div><div><br></div><div>Kris</div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 15, 2019 at 3:28 PM Phil Neumiller <<a href="mailto:pneumiller@directstream.com">pneumiller@directstream.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sure, you just need additional threads.  Note: accept is a blocking call so<br>
the thread that runs in (i.e. your server side will block until a packet is<br>
received).  You can write a polling loop using select, that doesn't block. <br>
The cleanest thing to do is have a thread for client(s) and one for server. <br>
I have done this with C++17 with TLS1_3_Client and TLS1_3_Server classes<br>
with accept loop member functions started as std::thread.<br>
<br>
<br>
<br>
-----<br>
Phillip Neumiller<br>
Platform Engineering<br>
Directstream, LLC<br>
--<br>
Sent from: <a href="http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html" rel="noreferrer" target="_blank">http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">This message is NOT encrypted
<br>--------------------------------
<br>Mr. Kristen J. Webb
<br>Chief Technology Officer
<br>Teradactyl LLC.
<br>2450 Baylor Dr. S.E.
<br>Albuquerque, New Mexico 87106
<br>Phone: 1-<span style="display:inline;font-size:inherit;padding:0pt;color:rgb(80,80,80)">505-338-6000</span>
<br>Email: <a href="mailto:kwebb@teradactyl.com" target="_blank">kwebb@teradactyl.com</a>
<br>Web: <a href="http://www.teradactyl.com" target="_blank">http://www.teradactyl.com</a>
<br>
<br><img src="https://drive.google.com/a/teradactyl.com/uc?id=1AtTRUbNsHoJJEO8vs4zd6D2oON5Evwq4&export=download"><br><br>Providers of Scalable Backup Solutions
<br>   for Unique Data Environments
<br>
<br>--------------------------------
<br>NOTICE TO RECIPIENTS: Any information contained in or attached to this
<br>message is intended solely for the use of the intended recipient(s). If
<br>you are not the intended recipient of this transmittal, you are hereby
<br>notified that you received this transmittal in error, and we request
<br>that you please delete and destroy all copies and attachments in your
<br>possession, notify the sender that you have received this communication
<br>in error, and note that any review or dissemination of, or the taking of
<br>any action in reliance on, this communication is expressly prohibited.
<br>
<br>
<br>Regular internet e-mail transmission cannot be guaranteed to be secure
<br>or error-free. Therefore, we do not represent that this information is
<br>complete or accurate, and it should not be relied upon as such. If you
<br>prefer to communicate with Teradactyl LLC. using secure (i.e., encrypted
<br>and/or digitally signed) e-mail transmission, please notify the sender.
<br>Otherwise, you will be deemed to have consented to communicate with
<br>Teradactyl via regular internet e-mail transmission. Please note that
<br>Teradactyl reserves the right to intercept, monitor, and retain all
<br>e-mail messages (including secure e-mail messages) sent to or from its
<br>systems as permitted by applicable law
</div></div></div></div>