🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.protocols.iso.x400
Article #860

Re: X.400 and multimedia mail

#860
From: John H. Dale
Date: Fri, 11 Dec 1992 19:51
51 lines
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!jdale
References: <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