Article View: comp.protocols.iso.x400
Article #860Re: X.400 and multimedia mail
From: John H. Dale
Date: Fri, 11 Dec 1992 19:51
Date: Fri, 11 Dec 1992 19:51
51 lines
3061 bytes
3061 bytes
In <Bz2nu0.LCM@wimsey.bc.ca> sl@wimsey.bc.ca (Stuart Lynne) writes: >In article <1g4h48EINNt1v@uni-erlangen.de> mskuhn@immd4.informatik.uni-erlangen.de writes: >>bakker@cs.rulimburg.nl (Harm Bakker) writes: >> >> rare escape sequences, ...). Messages are streams of bytes delimited by >> length indicators, the easiest, most efficient and most robust >> method possible. >Not too quible too much. But I'd hesitate to say that it's the easiest. >If a data producer must know exactly how much data he's going to produce >he will have to buffer it before sending so he can count it. If you have a >method of indicating end of data you can simply send it as you produce it. X.400 is for messaging, so you normally have the whole message before you start sending. However, the BER encoding technique uses the lengths in a way that does not require you to know before you start sending. Your are allowed to send the string as a series of short strings. Each substring has a specific length indicator chosen at the convenience of the sender, but the overall string constructed from all these substrings does not have the length specified in advance. If you have access to a presentation on BER, look up constructed encoding of strings. (I don't know X.400, but I don't think the length is carried in the message header, so I doubt you need to know the length before you start sending.) >For a real life example, when receive incoming fax images I don't know >ahead of time how big a received image will be. If I can't save the image >until I know how big it is then I'm constrained to bufferring it and then >writing it out in one large chunk instead of small chunks as I receive it. >This impacts further on the design because I must now ensure that I can >keep the remote fax station online without sending new data while I save >the previous page. Which if it's very large may take some time. Or be >prepared to buffer multiple pages. The Reliable Transfer Service protocol that X.400 uses explicitly deals with breaking the data up into conventient chunks, and provides for starting where you left off if you lose your connection or interrupt the transmission for some reason. >-- >Stuart Lynne <sl@wimsey.com> ......................... UNIX Facsimile Software >Wimsey Information Technologies ................... moderator biz.sco.binaries >uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z >PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd John Dale Corporation for Open Systems jdale@cos.com
Technical Details
Message-ID:
<jdale.724103461@cos>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!cos!cos!jdaleReferences:
<bakker.723813361@cs.rulimburg.nl> <1g4h48EINNt1v@uni-erlangen.de> <Bz2nu0.LCM@wimsey.bc.ca>Show Full Headers
Complete Article Headers
Newsgroups: comp.protocols.iso.x400 Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!cos!cos!jdale From: jdale@cos.com (John H. Dale) Subject: Re: X.400 and multimedia mail Message-ID: <jdale.724103461@cos> Keywords: X.400 Organization: Corporation for Open Systems References: <bakker.723813361@cs.rulimburg.nl> <1g4h48EINNt1v@uni-erlangen.de> <Bz2nu0.LCM@wimsey.bc.ca> Date: Fri, 11 Dec 1992 19:51:01 GMT Lines: 51