That’s not just SSL. Only the app knows when it has received all the data. Only 
then should it close the socket.   So an app waits for a certain amount of time 
or until it gets and end-of-data indicator. That might be a specific byte 
sequence or it might be a closed connection (eg ftp).

There is a mechanism to close just the sending side, if that’s needed by the 
application protocol. 

Regards,
Alan

Alan Altmark
Senior z/VM Software Engineer
IBM zSystems
Endicott, NY         USA

> On Aug 15, 2023, at 4:44 AM, Rob van der Heij <[email protected]> wrote:
> 
> I suspect this is a feature of the VM SSL implementation to close the
> inbound socket when the application closes the outbound connection,
> discarding any data that is in transit outside or in the SSL path. That
> happened initially also in the other direction, but I was able to change
> some minds because you have little control over when the other side closes
> the socket. For the outbound socket, we can avoid closing it early with a
> FANIN and ELASTIC and waiting for the inbound connection to close.
> Like this:
> ... | i: fanin | tcpclient ... | ..  hole | elastic | i:
> 
> A working example is here:
> https://gist.githubusercontent.com/rvdheij/fb03574799200c14f636ef7913c753b9 
> I will have a look why LINGER doesn't postpone closing the socket for the
> SECURE case. Maybe I left a piece of pipe on the floor. If you remove the
> feedback to FANIN, you'll notice it does not get anything.
> 
> Sir Rob the Plumber
> 
>> On Tue, 15 Aug 2023 at 02:16, Donald Russell <[email protected]> wrote:
>> 
>> I also use the linger 10 and timeout 15 options on tcpclient.
>> 
>> Typo in the original message: should be I CANNOT explain why one works and
>> the other doesn’t.
>> 
>> 
>> 
>> On Mon, Aug 14, 2023 at 16:48 Donald Russell <[email protected]>
>> wrote:
>> 
>>> I wrote a CMS exec to send an http post request using the tcpclient pipe
>>> stage.
>>> 
>>> When I use port 80 everything works as expected.  I get the http response
>>> and so on.
>>> 
>>> If I change to use port 443 and specify the secure getsecinfo options,
>> the
>>> request goes to the web server, the secinfo data shows tls1.2 was
>>> negotiated ok, the web server log shows the post request complete, but
>>> tcpclient doesn’t output any of the https response. I get “0 socket
>> closed”.
>>> 
>>> Any suggestions for what to look at? I can explain why one works and the
>>> other not.  🙁
>>> 
>>> 
>>> 
>>> 
>> 

Reply via email to