osa538b@vaxc.cc.monash.edu.au (Alan Chee) (07/14/90)
-- hello all, Company I'm working for currently uses X400 to exchange mail between two office systems. Namely, CEO on DG and ALL-IN-1 on VAX. We're experiencing reproducible errors when large ( as in 100+ ) distribution list is used to send mail between the two system. WHat happens is that the VAX's MRX establishes connection with the DG's X400 and begins sending. The DG then terminates the connection with error saying unexpected terminator encountered. Naturally, the VAX recovers tries again etc. and we have to delete the session to allow other messages through. Of course, we have DG and DEC looking into it. Mean time, I was wondering if anyone else have come across such problems or is there some unknown limit to number of addressees in the X400 protocols ? Alternatively, could the vendor implementation be the cause ? I actually seen log messages larger (in body text) gone thru successfully but short/medium messages with large distribution list have held up the sessions. Any light thrown would greatly appreciated. Thanks in advance ----------------------------------------------------------------------------- Alan Chee, | internet: alanC@VAXC.cc.monash.edu.au P.O. Box 413, World Trade Centre, | X.25: PSI%AUSTPAC.0505224122018::chee Melbourne, Vic. AUSTRALIA 3005 | voice: +61 3 345 4717 (BH) -----------------------------------------------------------------------------
andrewf@syacus.acus.oz (Andrew Friedman) (07/16/90)
In article <33587.269e46c2@vaxc.cc.monash.edu.au> osa538b@vaxc.cc.monash.edu.au (Alan Chee) writes: > [description of interop problem deleted] > >Of course, we have DG and DEC looking into it. Mean time, I was wondering if >anyone else have come across such problems or is there some unknown limit to >number of addressees in the X400 protocols ? > Limits are typically not documented in the X.400 (1984) set of standards, for that you need to know the limits imposed by the profile that the implementations have been built or configured for. Assuming the machines have been configured for the NIST profile then the limit is 32K-1 recipients. You might like to check with your vendors, if these two implementations have performed the OSInet test that tests whether implementations support a large number of receipients. Alternatively, some OSInet folks might like to say. >Alternatively, could the vendor implementation be the cause ? I actually seen >log messages larger (in body text) gone thru successfully but short/medium >messages with large distribution list have held up the sessions. Yes.
tim@piglet.planet.bt.co.uk (Tim Maude,B81 G61,6734,) (07/16/90)
> > > Of course, we have DG and DEC looking into it. Mean time, I was wondering if > anyone else have come across such problems or is there some unknown limit to > number of addressees in the X400 protocols ? > The limit that is usually set on the size of a recipient list is 32K-1. I believe that is what the profiles say it should be - so therer should be no problem with your list of 100. ------------------------------------------------------------------- Tim Maude RT7431 email: tim@planet.bt.co.uk British Telecom Research Laboratories phone: +44 473 646734 Martlesham Heath fax: +44 473 642163 Ipswich IP5 7RE U.K. -------------------------------------------------------------------
remedios@hpindda.cup.hp.COM (Jim Remedios) (07/17/90)
/ hpindda:comp.protocols.iso.x400 / osa538b@vaxc.cc.monash.edu.au (Alan Chee) / 3:05 pm Jul 13, 1990 / > Of course, we have DG and DEC looking into it. Mean time, I was wondering if > anyone else have come across such problems or is there some unknown limit to > number of addressees in the X400 protocols ? If you are NIST conformant, the maximum number of recipients in a single P1 MPDU is 32767. P2 does not limit the number of recipients. > > Alternatively, could the vendor implementation be the cause ? Always a possibility. -- Jim Remedios remedios@hpda.hp.com
harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) (07/19/90)
This bounced off my USENET mailer, so I send it through other channels...
sorry for the ehader confusion....
Newsgroups: comp.protocols.iso.x400
Path: lear!hta
From: harald.alvestrand@elab-runit.sintef.no
Message-ID: <1990Jul18.094416.6009@idt.unit.no>
Keywords: Many recipients, Timeout
Reply-To: harald.alvestrand@elab-runit.sintef.no
Organization: ELAB-RUNIT, SINTEF, Norway
References: <33587.269e46c2@vaxc.cc.monash.edu.au> <853@syacus.acus.oz>
Date: Wed, 18 Jul 90 09:44:16 GMT
Well......I had a similar problem running EAN.
Of course, there is no connection whatsoever between DG's X.400 and EAN,
which is commercialized as OSIWARE's Messenger.400, and the problem may have
been solved, but still......
What happened was that EAN received a message with 400 recipients.
All the recipients were local to the machine, which is important to what
happened.
It first received the blocks containing the P1 envelope.
It then proceeded to route the message, opening all the 400 UA queues and
writing the header to them.
It THEN went back to the association, trying to get the next block.
BUT: The previous step had taken 15 MINUTES, and the sender had timed out.
Result: Approximately as described.
Solutions? 2 - 1 done, the other may work.
1) Put a redistribution list on the receiving machine. This is
guaranteed to work.
2) Push the timeout up to whatever it needs to be.
Permanent solution: Fix the software so it eats the complete message before
starting to route on it. RTS-level aborts are a WRONG way of handling problems
arising from the content of the message.
Cheers,
Harald
P.S: At the time, message processing took extraordinary amounts of time because
of a very slow address format converter. It might not be a problem in
ordinary EAN usage.
On the other hand, it takes time to set up 400 UAs for testing.
I have other problems to solve. So I have not tried this again.
Good luck!Neil.K.Koorland@vancouver.osiware.telecom#d#canada.ca (Neil Koorland) (07/20/90)
> From: harald.alvestrand@elab-runit.sintef.no > > Well......I had a similar problem running EAN. > Of course, there is no connection whatsoever between DG's X.400 and EAN, > which is commercialized as OSIWARE's Messenger.400, and the problem may have > been solved, but still...... > Just to clarify this very common misconception : the EAN implementation from UBC is indeed the basis for OSIWARE's Messenger 400 X.400 product. However, the two systems have diverged significantly since 1985 when EAN was first commercialized. In that time in particular, one of the features added to Messenger 400 that still does not exist in EAN is the ability to handle 32K-1 recipients (in order to conform to the NIST and EWOS profiles). EAN has a documented limit of 256 recipients. The problem described therefore would not occur with Messenger 400, which regularly handles large recipient lists. I would be happy to expand on other major differences between the two systems "offline" if anybody is interested. Neil Koorland Director of Research OSIware Inc. 4370 Dominion St Burnaby B.C. CANADA V5G 4L7
thurlow@uunet.uu.NET (Robert Thurlow) (07/20/90)
harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) writes: >Well......I had a similar problem running EAN. >Of course, there is no connection whatsoever between DG's X.400 and EAN, >which is commercialized as OSIWARE's Messenger.400, and the problem may have >been solved, but still...... I was on the project that fixed Messenger 400 to handle 32K-1 recipients. It still is an interesting test to run, but it works much better than the then-current EAN stuff did. Rob T -- Rob Thurlow, thurlow@convex.com or thurlow%convex.com@uxc.cso.uiuc.edu ---------------------------------------------------------------------- A geek is a terrible thing to waste. Help support the 1990 "Get A Life" Initiative! Send your contributions now! Operators are standing by!