home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / tcpip / ibmpc / 7354 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  3.4 KB
  1. Xref: sparky comp.protocols.tcp-ip.ibmpc:7354 comp.sys.novell:11346
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!hellgate.utah.edu!cc.usu.edu!jrd
  3. From: jrd@cc.usu.edu (Joe Doupnik)
  4. Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.sys.novell
  5. Subject: Re: ODI information requested.
  6. Message-ID: <1993Jan11.155845.62631@cc.usu.edu>
  7. Date: 11 Jan 93 15:58:45 MDT
  8. References: <1993Jan9.085223.6519@osuunx.ucc.okstate.edu> <1993Jan11.200015.26324@novell.com> <1iskr9INNqfs@usenet.INS.CWRU.Edu>
  9. Organization: Utah State University
  10. Lines: 49
  11.  
  12. In article <1iskr9INNqfs@usenet.INS.CWRU.Edu>, trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
  13. > In article <1993Jan11.200015.26324@novell.com> dmurphy@novell.com 
  14. >(David Murphy) writes:
  15. >>This is the way it was designed and not a bug.  The reasoning being
  16. >>that people would generally only being using a Stack for a certain form
  17. >>of connectivity, eg. TCP/IP from 1 company.
  18. > 
  19. > I think it's more because it's hard to figure out just how to share one
  20. > Ethernet address between multiple protocol stacks.  For example, just
  21. > how would you load more than one IPX for the same Ethernet address?
  22. > 
  23. > The same applies to IP, though there has been a mechanism developed (in
  24. > NDIS) that permits multiple stacks of the same type, as long as they all
  25. > cooperate in a certain way.
  26. > 
  27. > There's more than assumptions here.  Most protocols are not designed for
  28. > more than one stack per Ethernet card, and that makes putting more than
  29. > one stack per card quite hard.  Call it a protocol deficiency if you want;
  30. > that doesn't make it easier.
  31. > 
  32. > -- 
  33. > Stephen Trier                      "We want to offer you a price that you
  34. > Network software type               just can't afford to take advantage of."
  35. > Case Western Reserve University         - Sales blurb from HSC Software
  36. > trier@ins.cwru.edu
  37. -------------
  38.     Close, but not quite the story. Multiple protocols can share a board
  39. with little problem these days, and ODI, NDIS, and PD modules are designed
  40. for this. The difficulty is not sending packets of the same protocol type
  41. from multiple (same type) stacks. The difficulty is, however, receiving packets
  42. when there are contending receipients. A packet will be delivered just once,
  43. but to whom? Well, you can't tell from the outside so one stack gets the 
  44. packet, whether it belongs there or not, and the others starve. Misdelivery
  45. has generally unpleasant conseqences. Delivering the same packet to all 
  46. contenders is misdelivery to N-1 stacks, a worse problem than just one.
  47.     A protocol stack is, for the most part, a decoder and encoder of the
  48. information in a packet, and that's a messy detailed business. ODI, NDIS, PD
  49. are not protocol stacks but are packet handlers of roughly similar nature; 
  50. they are interested in physical addresses and the like rather than the deep
  51. interiors of what one protocol may say. They are good at separating one
  52. protocol flavor from another, because packets are built with this in mind,
  53. but can't distinguish IP for stack 1 from IP for stack 2 etc.
  54.     Take this one step forward. UPD over IP. It's connectionless so no
  55. trail is left about who might want the incoming packet. The trail is an
  56. attempt to track a conversation, a la pktmux. Doesn't work with UPD, and
  57. in many cases it does not work with TCP.
  58.     If you want multiple applications which use the same protocol then
  59. either run them all over the same protocol stack, or get another lan adapter.
  60.     Joe D. 
  61.