home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / protocol / iso / x400 / 703 < prev    next >
Encoding:
Text File  |  1992-12-11  |  2.9 KB  |  63 lines
  1. Newsgroups: comp.protocols.iso.x400
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!cos!cos!jdale
  3. From: jdale@cos.com (John H. Dale)
  4. Subject: Re: X.400 and multimedia mail
  5. Message-ID: <jdale.724103461@cos>
  6. Keywords: X.400
  7. Organization: Corporation for Open Systems
  8. References: <bakker.723813361@cs.rulimburg.nl> <1g4h48EINNt1v@uni-erlangen.de> <Bz2nu0.LCM@wimsey.bc.ca>
  9. Date: Fri, 11 Dec 1992 19:51:01 GMT
  10. Lines: 51
  11.  
  12. In <Bz2nu0.LCM@wimsey.bc.ca> sl@wimsey.bc.ca (Stuart Lynne) writes:
  13.  
  14. >In article <1g4h48EINNt1v@uni-erlangen.de> mskuhn@immd4.informatik.uni-erlangen.de writes:
  15. >>bakker@cs.rulimburg.nl (Harm Bakker) writes:
  16. >>
  17. >>  rare escape sequences, ...). Messages are streams of bytes delimited by
  18. >>  length indicators, the easiest, most efficient and most robust
  19. >>  method possible.
  20.  
  21. >Not too quible too much. But I'd hesitate to say that it's the easiest. 
  22.  
  23. >If a data producer must know exactly how much data he's going to produce
  24. >he will have to buffer it before sending so he can count it. If you have a
  25. >method of indicating end of data you can simply send it as you produce it.
  26.  
  27. X.400 is for messaging, so you normally have the whole message before
  28. you start sending.  However, the BER encoding technique uses the lengths
  29. in a way that does not require you to know before you start sending.
  30. Your are allowed to send the string as a series of short strings.
  31. Each substring has a specific length indicator chosen at the convenience
  32. of the sender, but the overall string constructed from all these
  33. substrings does not have the length specified in advance.  If you have
  34. access to a presentation on BER, look up constructed encoding of strings.
  35.  
  36. (I don't know X.400, but I don't think the length is carried in
  37. the message header, so I doubt you need to know the length before
  38. you start sending.)
  39.  
  40. >For a real life example, when receive incoming fax images I don't know
  41. >ahead of time how big a received image will be. If I can't save the image
  42. >until I know how big it is then I'm constrained to bufferring it and then
  43. >writing it out in one large chunk instead of small chunks as I receive it.
  44. >This impacts further on the design because I must now ensure that I can
  45. >keep the remote fax station online without sending new data while I save
  46. >the previous page. Which if it's very large may take some time. Or be 
  47. >prepared to buffer multiple pages. 
  48.  
  49. The Reliable Transfer Service protocol that X.400 uses explicitly deals
  50. with breaking the data up into conventient chunks, and provides for
  51. starting where you left off if you lose your connection or interrupt
  52. the transmission for some reason.
  53.  
  54. >-- 
  55. >Stuart Lynne <sl@wimsey.com> ......................... UNIX Facsimile Software
  56. >Wimsey Information Technologies ................... moderator biz.sco.binaries
  57. >uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z
  58. >PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd
  59.  
  60. John Dale
  61. Corporation for Open Systems
  62. jdale@cos.com
  63.