home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / protocol / ibm / 856 < prev    next >
Encoding:
Text File  |  1992-12-21  |  1.6 KB  |  35 lines
  1. Newsgroups: comp.protocols.ibm
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!netcomsv!dlb!dave
  3. From: dave@dlb.com (Dave Buck)
  4. Subject: Re: SDLC Point-to-Point Full Duplex
  5. Message-ID: <1992Dec19.001256.13187@dlb.com>
  6. Keywords: SDLC
  7. Reply-To: dave@dlb.com (Dave Buck)
  8. Organization: D.L.Buck & Associates, Inc.; San Jose, Calif.
  9. References: <BzAwJq.9nM@world.std.com>
  10. Date: Sat, 19 Dec 1992 00:12:56 GMT
  11. Lines: 22
  12.  
  13. In article <BzAwJq.9nM@world.std.com> mdivya@world.std.com (Marigowda Divya) writes:
  14. >This is regarding SDLC Point-to-Point Full Duplex.  Question is,
  15. >if the primary sends a Poll (eg: RR-P) followed by
  16. >couple of I-frames, should the secondary stick with the original
  17. >Nr (at the time the poll was received), or should it keep updating
  18. >the Nr;  correspondingly, should the primary do the same?
  19.  
  20. In fact numerous implementations including IBM's do seem to change the
  21. Nr value from I frame to adjacent I frame or RR. But your question is
  22. "should they", not "do they" ... that is certainly unclear from the
  23. IBM specs. I would be so bold as to state that a good implementation
  24. should accept such behavior from a peer, but provide an option for
  25. this behavior for local transmissions.
  26.  
  27. >If this were to be true, then isn't it possible, that within one
  28. >POLL/FINAL exchange, any number of I-frames can be exchanged
  29. >between the Primary and the Secondary.
  30.  
  31. Yes. Which makes it look very much like an HDLC implementation.
  32. -- 
  33. Dave Buck   dave@dlb.com   {amdahl,ames,daver,netcomsv,sun,zygot}!dlb!dave
  34. D. L. Buck and Associates, Inc.;   San Jose, California;    (408) 972-2825
  35.