ucx$c_full_duplex_close and Multinet BG: driver dilema

[David J Dachtera]

Hi,
Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG: driver.
When I try to set the Socket Option ucx$c_full_duplex_close (on its own, or
in the same call to create the socket) I get SS$_PROTOCOL returned.
This option is obviously available in UCX, and the TCPWare docs say it's
been supported for the last ten years but somehow it's never been included
with Multinet. Is that correct? Is there a version later than 5.0 that
supports it?
I'm now having to code around the problem (by trying for FDC and if I get
ss$_protocol then drop the option) but full_duplex_close is a pretty damned
useful piece of functionality and I'm really curious as to the reasons
behind the lack of support or whether there are any plans to include it in a
future version?

I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
respond.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/

Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/

[Richard Maher]

Post by David J Dachtera
I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
respond.

Thanks David,

I've been told the issue still exists in 5.1 and I couldn't find any
SO_FULL_DUPLEX in the Multinet Docs (That seem to have all the other
SO_NODELAY etc) so I'm resigned to making the code changes, but you never
know something might pop-up.

Cheers Richard Maher

Post by David J Dachtera

Hi,
Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG: driver.
When I try to set the Socket Option ucx$c_full_duplex_close (on its own, or
in the same call to create the socket) I get SS$_PROTOCOL returned.
This option is obviously available in UCX, and the TCPWare docs say it's
been supported for the last ten years but somehow it's never been included
with Multinet. Is that correct? Is there a version later than 5.0 that
supports it?
I'm now having to code around the problem (by trying for FDC and if I get
ss$_protocol then drop the option) but full_duplex_close is a pretty damned
useful piece of functionality and I'm really curious as to the reasons
behind the lack of support or whether there are any plans to include it in a
future version?

I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
respond.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
http://www.djesys.com/vms/soho/
http://www.djesys.com/vms/ia32/
http://www.djesys.com/vms/support/

[Richard Maher]

Hi,

This question's easier than the first one so please help if you've done
this. I'd simply like to see a $QIO _BG: driver example example of a server
(or client) receiving an OOB character (*NOT* IN-LINED) from their partner
and displaying it. I have code that works perfectly well on UCX and TCPware
but on Multinet the following happens: -

My <io$_setmode!io$m_outband> works and the AST fires as expected.
Then I go to read the OOB character with a $qio <io$_readvblk!io$m_nowait>
plus ucx$c_msg_oob as P4 - and the results I get vary from ss$_badparam to
ss$_suspended
So I say great, it was a false alarm and reset the OOBATTN AST which then
fires immediately and says "Nope there's definitely an OOB character here!
(It's just that we're not gonna let you read it, so loop around madly for a
while :-)"

Has anyone else experienced this or alternatively got a working example
they'd be willing to share?

Is the ss$_badparam really telling me there's a bad parameter and not just a
missing OOB?
Would a previous io$_sensemode have interfered with the sioatmark?
Is there some incantation or dead-chicken-waving such as
<io$_readvblk!io$m_nowait!io$m_interrupt> rather than using P4 flags?
(As a side issue and although I can't produce an example here, I am also
open to the idea that elsewhere Multinet will return a ss$_suspended to a
non-blocking read even if the pipe is broken, but that's one for another
day)

I must be doing something wrong but the fact that it's rockin' and rollin'
on UCX is a bit off-putting.

Thanks for any help.

Cheers Richard Maher

PS. Is it just me that thinks TCPware is a *whole* lot more UCX BG Driver
compatible than Multinet?

Post by David J Dachtera

Hi,
Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG: driver.
When I try to set the Socket Option ucx$c_full_duplex_close (on its own, or
in the same call to create the socket) I get SS$_PROTOCOL returned.
This option is obviously available in UCX, and the TCPWare docs say it's
been supported for the last ten years but somehow it's never been included
with Multinet. Is that correct? Is there a version later than 5.0 that
supports it?
I'm now having to code around the problem (by trying for FDC and if I get
ss$_protocol then drop the option) but full_duplex_close is a pretty damned
useful piece of functionality and I'm really curious as to the reasons
behind the lack of support or whether there are any plans to include it in a
future version?

I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
respond.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
http://www.djesys.com/vms/soho/
http://www.djesys.com/vms/ia32/
http://www.djesys.com/vms/support/

[Graham Burley]

Nothing useful to say, as usual ;-), just hoping this reply with a valid
e-mail address will make it to the INFO-MULTINET mailing list which
*should* be gateway'd to vmsnet.networks.tcp-ip.multinet.

Post by Richard Maher
Hi,
This question's easier than the first one so please help if you've done
this. I'd simply like to see a $QIO _BG: driver example example of a server
(or client) receiving an OOB character (*NOT* IN-LINED) from their partner
and displaying it. I have code that works perfectly well on UCX and TCPware
but on Multinet the following happens: -
My <io$_setmode!io$m_outband> works and the AST fires as expected.
Then I go to read the OOB character with a $qio <io$_readvblk!io$m_nowait>
plus ucx$c_msg_oob as P4 - and the results I get vary from ss$_badparam to
ss$_suspended
So I say great, it was a false alarm and reset the OOBATTN AST which then
fires immediately and says "Nope there's definitely an OOB character here!
(It's just that we're not gonna let you read it, so loop around madly for a
while :-)"
Has anyone else experienced this or alternatively got a working example
they'd be willing to share?
Is the ss$_badparam really telling me there's a bad parameter and not just a
missing OOB?
Would a previous io$_sensemode have interfered with the sioatmark?
Is there some incantation or dead-chicken-waving such as
<io$_readvblk!io$m_nowait!io$m_interrupt> rather than using P4 flags?
(As a side issue and although I can't produce an example here, I am also
open to the idea that elsewhere Multinet will return a ss$_suspended to a
non-blocking read even if the pipe is broken, but that's one for another
day)
I must be doing something wrong but the fact that it's rockin' and rollin'
on UCX is a bit off-putting.
Thanks for any help.
Cheers Richard Maher
PS. Is it just me that thinks TCPware is a *whole* lot more UCX BG Driver
compatible than Multinet?

Post by David J Dachtera

Hi,

driver.

Post by David J Dachtera

When I try to set the Socket Option ucx$c_full_duplex_close (on its own,

or

Post by David J Dachtera

in the same call to create the socket) I get SS$_PROTOCOL returned.
This option is obviously available in UCX, and the TCPWare docs say it's
been supported for the last ten years but somehow it's never been

included

Post by David J Dachtera

with Multinet. Is that correct? Is there a version later than 5.0 that
supports it?
I'm now having to code around the problem (by trying for FDC and if I

get

Post by David J Dachtera

ss$_protocol then drop the option) but full_duplex_close is a pretty

damned

Post by David J Dachtera

useful piece of functionality and I'm really curious as to the reasons
behind the lack of support or whether there are any plans to include it

in a

Post by David J Dachtera

future version?

I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
respond.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
http://www.djesys.com/vms/soho/
http://www.djesys.com/vms/ia32/
http://www.djesys.com/vms/support/

[Richard Maher]

Hi,

We can leave the red-herring io$m_nowait/ss$_suspend issue behind us; UCX
doesn't care if the NOWAIT is dropped from the OOB Read, so I'm willing to
concede that it was superfluous and may have only served to confuse
Multinet. (It seems it is impossible to do an asynchronous
<io$_readvblk!io$m_interupt> and have the completion AST *only* fire when
the OOB has arrived; if it's not there then ss$_badparam is returned) This
is great, I can work with this!)

The problem remains that after an interrupt has arrived and been read
sucessfully by a $qio <io$_readvblk!io$m_interrupt> *or* io$readvblk with P4
as ucx$c_msg_oob, the next setting of the OOB Attention AST
<io$_setmode!io$m_outband> completes immediately (next AST) with
ss$_badparam returned to the subsequent OOB read. (And the tight CPU loop
ensues)

Diagnosis: a) The successful read of the OOB character is not cleaning up
and resetting the OOB-present flag to say that it's gone or b) The
io$setmode!io$m_oobattn function is not seeing the flag after being reset.

I vote for a) 'cos I've done a $dclast to do the reset, in case AST
reentrancy issues were involved, and I've toggled between
<io$_readvblk!io$m_interrupt> and io$_readvblk + ucx$c_msg_oob and I just
don't have any levers left to pull :-(

I've got two sheep stations and an oil-rig that says Multinet is not
resetting the OOB flag after a succesful oob read; Let's see your cards! Any
chance someone's gonna fix this?

Nobody using OOB functionality with Multinet? No application development
with Multinet/ Just use the spoon-fed tools out of the box? If it ain't SSH
it just ain't? You really need UCX if you're serious about rolling your own?

Cheers Richard Maher

PS. I've also tried *not* resetting the OOB AST a second time to see if
Multinet is a set and forget type of thing, but then it only fires the once
(as documented).

PPS. I'm the guy that found the buffer-overflowing stack-corrupter that is
Multinet's io$_acpcontrol (at least for inetacp$c_trans
inetacp_func$c_gethostbyaddr).

PPPS. I still believe Multinet is trigger-happy with ss$_suspend leading it
to conceal a broken network connection when ss$_linkdiscon would be the
appropriate error status, but I'll have to change my OOBATTN testing to
READATTN testing and that issue isn't really bothering me anyway. (If I'm
wrong I will report back)

Post by Richard Maher
Hi,
This question's easier than the first one so please help if you've done
this. I'd simply like to see a $QIO _BG: driver example example of a server
(or client) receiving an OOB character (*NOT* IN-LINED) from their partner
and displaying it. I have code that works perfectly well on UCX and TCPware
but on Multinet the following happens: -
My <io$_setmode!io$m_outband> works and the AST fires as expected.
Then I go to read the OOB character with a $qio <io$_readvblk!io$m_nowait>
plus ucx$c_msg_oob as P4 - and the results I get vary from ss$_badparam to
ss$_suspended
So I say great, it was a false alarm and reset the OOBATTN AST which then
fires immediately and says "Nope there's definitely an OOB character here!
(It's just that we're not gonna let you read it, so loop around madly for a
while :-)"
Has anyone else experienced this or alternatively got a working example
they'd be willing to share?
Is the ss$_badparam really telling me there's a bad parameter and not just a
missing OOB?
Would a previous io$_sensemode have interfered with the sioatmark?
Is there some incantation or dead-chicken-waving such as
<io$_readvblk!io$m_nowait!io$m_interrupt> rather than using P4 flags?
(As a side issue and although I can't produce an example here, I am also
open to the idea that elsewhere Multinet will return a ss$_suspended to a
non-blocking read even if the pipe is broken, but that's one for another
day)
I must be doing something wrong but the fact that it's rockin' and rollin'
on UCX is a bit off-putting.
Thanks for any help.
Cheers Richard Maher
PS. Is it just me that thinks TCPware is a *whole* lot more UCX BG Driver
compatible than Multinet?

Post by David J Dachtera

Hi,

driver.

Post by David J Dachtera

When I try to set the Socket Option ucx$c_full_duplex_close (on its

own,

Post by Richard Maher
or

Post by David J Dachtera

in the same call to create the socket) I get SS$_PROTOCOL returned.
This option is obviously available in UCX, and the TCPWare docs say it's
been supported for the last ten years but somehow it's never been

included

Post by David J Dachtera

with Multinet. Is that correct? Is there a version later than 5.0 that
supports it?
I'm now having to code around the problem (by trying for FDC and if I

get

Post by David J Dachtera

ss$_protocol then drop the option) but full_duplex_close is a pretty

damned

Post by David J Dachtera

useful piece of functionality and I'm really curious as to the reasons
behind the lack of support or whether there are any plans to include

it

Post by Richard Maher
in a

Post by David J Dachtera

future version?

I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
respond.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
http://www.djesys.com/vms/soho/
http://www.djesys.com/vms/ia32/
http://www.djesys.com/vms/support/

[Michael Corbett]

Post by Richard Maher
I've got two sheep stations and an oil-rig that says Multinet is not
resetting the OOB flag after a succesful oob read; Let's see your cards! Any
chance someone's gonna fix this?

I won't take that bet. I will bet that an upcoming UCXDRIVER ECO will contain
a fix for this.

Post by Richard Maher
Nobody using OOB functionality with Multinet? No application development
with Multinet/ Just use the spoon-fed tools out of the box? If it ain't SSH
it just ain't? You really need UCX if you're serious about rolling your own?

I can't recall a customer call that ever mentioned OOB. I don't know if any
of the MultiNet applications make use of it, I think telnet might but it
doesn't use BG. We try to make Multinet's UCXDRIVER compatible with UCX's
but obviously we sometimes fail. We do try to fix things when they are reported
to us.

regards
Mike

Post by Richard Maher
Cheers Richard Maher
PS. I've also tried *not* resetting the OOB AST a second time to see if
Multinet is a set and forget type of thing, but then it only fires the once
(as documented).
PPS. I'm the guy that found the buffer-overflowing stack-corrupter that is
Multinet's io$_acpcontrol (at least for inetacp$c_trans
inetacp_func$c_gethostbyaddr).
PPPS. I still believe Multinet is trigger-happy with ss$_suspend leading it
to conceal a broken network connection when ss$_linkdiscon would be the
appropriate error status, but I'll have to change my OOBATTN testing to
READATTN testing and that issue isn't really bothering me anyway. (If I'm
wrong I will report back)

Post by Richard Maher
Hi,
This question's easier than the first one so please help if you've done
this. I'd simply like to see a $QIO _BG: driver example example of a

server

Post by Richard Maher
(or client) receiving an OOB character (*NOT* IN-LINED) from their partner
and displaying it. I have code that works perfectly well on UCX and

TCPware

Post by Richard Maher
but on Multinet the following happens: -
My <io$_setmode!io$m_outband> works and the AST fires as expected.
Then I go to read the OOB character with a $qio <io$_readvblk!io$m_nowait>
plus ucx$c_msg_oob as P4 - and the results I get vary from ss$_badparam to
ss$_suspended
So I say great, it was a false alarm and reset the OOBATTN AST which then
fires immediately and says "Nope there's definitely an OOB character here!
(It's just that we're not gonna let you read it, so loop around madly for

a

Post by Richard Maher
while :-)"
Has anyone else experienced this or alternatively got a working example
they'd be willing to share?
Is the ss$_badparam really telling me there's a bad parameter and not just

a

Post by Richard Maher
missing OOB?
Would a previous io$_sensemode have interfered with the sioatmark?
Is there some incantation or dead-chicken-waving such as
<io$_readvblk!io$m_nowait!io$m_interrupt> rather than using P4 flags?
(As a side issue and although I can't produce an example here, I am also
open to the idea that elsewhere Multinet will return a ss$_suspended to a
non-blocking read even if the pipe is broken, but that's one for another
day)
I must be doing something wrong but the fact that it's rockin' and rollin'
on UCX is a bit off-putting.
Thanks for any help.
Cheers Richard Maher
PS. Is it just me that thinks TCPware is a *whole* lot more UCX BG Driver
compatible than Multinet?

Post by David J Dachtera

Hi,

driver.

Post by David J Dachtera

When I try to set the Socket Option ucx$c_full_duplex_close (on its

own,

Post by Richard Maher
or

Post by David J Dachtera

in the same call to create the socket) I get SS$_PROTOCOL returned.
This option is obviously available in UCX, and the TCPWare docs say

it's

Post by Richard Maher

Post by David J Dachtera

been supported for the last ten years but somehow it's never been

included

Post by David J Dachtera

with Multinet. Is that correct? Is there a version later than 5.0 that
supports it?
I'm now having to code around the problem (by trying for FDC and if I

get

Post by David J Dachtera

ss$_protocol then drop the option) but full_duplex_close is a pretty

damned

Post by David J Dachtera

useful piece of functionality and I'm really curious as to the reasons
behind the lack of support or whether there are any plans to include

it

Post by Richard Maher
in a

Post by David J Dachtera

future version?

I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC

will

Post by Richard Maher

Post by David J Dachtera
respond.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
http://www.djesys.com/vms/soho/
http://www.djesys.com/vms/ia32/
http://www.djesys.com/vms/support/

[Richard Maher]

Hi Michael,

Thanks for the reply and please let me take this opportunity to publicly
thank Richard Whalen for his help and solutions with these issues.

Post by Michael Corbett
I will bet that an upcoming UCXDRIVER ECO will contain
a fix for this.

I fold. (Evidently a wise decision :-)

Post by Michael Corbett
I can't recall a customer call that ever mentioned OOB. I don't know if any
of the MultiNet applications make use of it, I think telnet might but it
doesn't use BG.

Don't feel too bad; Java Server Sockets don't even provide a way to get the
OOB (unless inlined). But OOBs are an extremely useful server-interrupt
mechanism and I'm willing to wager that a lot more of your customers will be
using them in the not too distant future.

Post by Michael Corbett
We try to make Multinet's UCXDRIVER compatible with UCX's
but obviously we sometimes fail. We do try to fix things when they are reported
to us.

No one can question the veracity of those statements on this occasion.

Thanks again.

Cheers Richard Maher

PS. I said I'd report back on the ss$_suspend issue; here 'tis: -

1) If you specify the io$m_nowait when attemting to read an OOB then
Multinet always returns ss$_suspend even if the OOB character is there. It
appears that io$m_nowait is inappropriate for OOB reads as there is no such
thing as an asynchronous/delayed OOB with sockets. (If it's there you get it
and if it isn't you get ss$_badparam) I've changed my code to drop the
io$m_nowait modifier and, to date, am happy but I just wanted to point out
that UCX simply ignores it.

2) My other guess (About read attention ASTs and ss$_suspend) turned out to
be wrong. It's actually *ss$_shut* that is the problem :-( Please *never,
ever, ever* return this status unless the network is shutting down. I
observed this behaviour with 5.0: -

When a read attention AST is outstanding and the client closes the
connection then the AST fires just as it should (and as UCX does) but a
subsequent <io$_readvblk!io$m_nowait> (Hey, we're in a Read Attention AST so
there should be something there to read, right?) returns ss$_shut instead of
ss$_linkdiscon. I have had to code around this by using an asynchronous read
(as opposed to the readattn AST) and once again, to date, am happy, but it
is another inconsistency with UCX and the inappropriate use of the "Networks
going down people" status is a concern.

Post by Michael Corbett

Post by Richard Maher
I've got two sheep stations and an oil-rig that says Multinet is not
resetting the OOB flag after a succesful oob read; Let's see your cards! Any
chance someone's gonna fix this?

I won't take that bet. I will bet that an upcoming UCXDRIVER ECO will contain
a fix for this.

Post by Richard Maher
Nobody using OOB functionality with Multinet? No application development
with Multinet/ Just use the spoon-fed tools out of the box? If it ain't SSH
it just ain't? You really need UCX if you're serious about rolling your own?

I can't recall a customer call that ever mentioned OOB. I don't know if any
of the MultiNet applications make use of it, I think telnet might but it
doesn't use BG. We try to make Multinet's UCXDRIVER compatible with UCX's
but obviously we sometimes fail. We do try to fix things when they are reported
to us.
regards
Mike

Post by Richard Maher
Cheers Richard Maher
PS. I've also tried *not* resetting the OOB AST a second time to see if
Multinet is a set and forget type of thing, but then it only fires the once
(as documented).
PPS. I'm the guy that found the buffer-overflowing stack-corrupter that is
Multinet's io$_acpcontrol (at least for inetacp$c_trans
inetacp_func$c_gethostbyaddr).
PPPS. I still believe Multinet is trigger-happy with ss$_suspend leading it
to conceal a broken network connection when ss$_linkdiscon would be the
appropriate error status, but I'll have to change my OOBATTN testing to
READATTN testing and that issue isn't really bothering me anyway. (If I'm
wrong I will report back)

Post by Richard Maher
Hi,
This question's easier than the first one so please help if you've done
this. I'd simply like to see a $QIO _BG: driver example example of a

server

Post by Richard Maher
(or client) receiving an OOB character (*NOT* IN-LINED) from their partner
and displaying it. I have code that works perfectly well on UCX and

TCPware

Post by Richard Maher
but on Multinet the following happens: -
My <io$_setmode!io$m_outband> works and the AST fires as expected.
Then I go to read the OOB character with a $qio

<io$_readvblk!io$m_nowait>

Post by Michael Corbett

Post by Richard Maher

Post by Richard Maher
plus ucx$c_msg_oob as P4 - and the results I get vary from ss$_badparam to
ss$_suspended
So I say great, it was a false alarm and reset the OOBATTN AST which then
fires immediately and says "Nope there's definitely an OOB character here!
(It's just that we're not gonna let you read it, so loop around madly for

a

Post by Richard Maher
while :-)"
Has anyone else experienced this or alternatively got a working example
they'd be willing to share?
Is the ss$_badparam really telling me there's a bad parameter and not just

a

Post by Richard Maher
missing OOB?
Would a previous io$_sensemode have interfered with the sioatmark?
Is there some incantation or dead-chicken-waving such as
<io$_readvblk!io$m_nowait!io$m_interrupt> rather than using P4 flags?
(As a side issue and although I can't produce an example here, I am also
open to the idea that elsewhere Multinet will return a ss$_suspended to a
non-blocking read even if the pipe is broken, but that's one for another
day)
I must be doing something wrong but the fact that it's rockin' and rollin'
on UCX is a bit off-putting.
Thanks for any help.
Cheers Richard Maher
PS. Is it just me that thinks TCPware is a *whole* lot more UCX BG Driver
compatible than Multinet?

Post by David J Dachtera

Hi,

driver.

Post by David J Dachtera

When I try to set the Socket Option ucx$c_full_duplex_close (on its

own,

Post by Richard Maher
or

Post by David J Dachtera

in the same call to create the socket) I get SS$_PROTOCOL returned.
This option is obviously available in UCX, and the TCPWare docs say

it's

Post by Richard Maher

Post by David J Dachtera

been supported for the last ten years but somehow it's never been

included

Post by David J Dachtera

with Multinet. Is that correct? Is there a version later than 5.0 that
supports it?
I'm now having to code around the problem (by trying for FDC and if I

get

Post by David J Dachtera

ss$_protocol then drop the option) but full_duplex_close is a pretty

damned

Post by David J Dachtera

useful piece of functionality and I'm really curious as to the reasons
behind the lack of support or whether there are any plans to include

it

Post by Richard Maher
in a

Post by David J Dachtera

future version?

I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC

will

Post by Richard Maher

Post by David J Dachtera
respond.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
http://www.djesys.com/vms/soho/
http://www.djesys.com/vms/ia32/
http://www.djesys.com/vms/support/