| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2185.1 | supporting information | FORTY2::JONES | Neil | Fri May 30 1997 04:44 | 37 |
|
Pascal,
We had to do the same work for the MAILbus 400 Message Store. This
functionality is available in our latest base-level.
When we originally used the XTI programming interface we could only
specify a qlen of 1. This means that XTI can only keep one pending
connection. If 2 connection requests arrive simultaneously then one
will be rejected at the Transport Level.
We now have a bigger qlen value. This means the MS has to keep track of
more connection requests as XTI does not queue them. Typically it goes
like this
t_listen indicates connection request 1
t_accept accept req 1
t_listen indicates req 2
!!! req 3 arrives
t_accept try to accept req 2 fails have to check why it failed
t_look says call t_listen
t_listen indicates req 3
t_accept try again to accept req 2
t_accept accept req 2
and so on...
You may have spotted that this does not completely solve the problem.
If our qlen=X and X connections arrive simultaneously then you still
get the Transport disconnect. However the probabilty of this happening
decreases as X increases.
I know this doesn't answer your questions but I hope it helps...
Regards
Neil
|
| 2185.2 | | wasted.zk3.dec.com::matt | The Code Warrior | Fri May 30 1997 10:23 | 3 |
| If you can upgrade to Digital UNIX V3.2G, you can use the sominconn
sysconfig attribute to resolve the problem. Otherwise, you are pretty
much SOL.
|
| 2185.3 | SOL ? | NNTPD::"[email protected]" | Pascal | Mon Jun 02 1997 09:08 | 6 |
| Thanks Neil & Matt for your advises..
Matt, I will tell you if I'm SOL if you tell me what it means... :-)
Pas.
[Posted by WWW Notes gateway]
|
| 2185.4 | | ABBYRD::RMULAC::S_WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering (303) 840-2986 | Mon Jun 02 1997 10:10 | 7 |
| >If you can upgrade to Digital UNIX V3.2G, you can use the sominconn
Yes this will allow XTI to queue multiple concurrent inbound CR TPDU's, but if
the application still does not respond appropriately to t_accept() returning a
t_look error you're going to still have problems.
--Scott
|
| 2185.5 | How does the OSAK API react ? | BIKINI::DITE | John Dite@RTO DTN 865-4065 | Tue Jun 03 1997 05:03 | 9 |
| Scott,
>Yes this will allow XTI to queue multiple concurrent inbound CR TPDU's, but if
>the application still does not respond appropriately to t_accept() returning a
>t_look error you're going to still have problems.
I assume that the OSAK API library routines that sit on top of XTI do.
John
|
| 2185.6 | | ABBYRD::RMULAC::S_WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering (303) 840-2986 | Tue Jun 03 1997 09:10 | 18 |
| >I assume that the OSAK API library routines that sit on top of XTI do.
Nope. This will manifest as "transport congestion" errors being logged when the
problem happens. OSAK was coded incorrectly, and cannot handle multiple
concurrent CR TPDU's. We have actually 2 solutions; we will be releasing an
OSAK in an upcoming ECO/MUP which contains a special version of t_accept() that
does not return the t_look error. This is a temporary solution. At some future
release (still being negotiated) we will be putting out a version of OSAK that
correctly handles a t_look error from t_accept() and internally queues the CR
TPDU's - we can't do this with an ECO/MUP though because it will break X.500,
and will require coding changes and a new release of X.500.
If you are encountering transport congestion errors with an OSAK application
(any application other than 1984 X.400 mail) we can provide the special version
of OSAK prior to the ECO/MUP - just escalate an IPMT. If it's 1984 X.400 mail
then you'll need a special version of MTA in addition to the OSAK fixes.
--Scott
|