Banyan VINES: Difference between revisions
adding interwiki to Bahasa Indonesia |
Missileboi (talk | contribs) Add operating system infobox, as VINES is also an OS, not just a protocol. |
||
(144 intermediate revisions by more than 100 users not shown) | |||
Line 1: | Line 1: | ||
{{short description|Discontinued network operating system}} |
|||
'''Banyan VINES''' (for ''Virtual Integrated NEtwork Service'') was a [[computer]] network [[operating system]] and the set of computer [[network protocol]]s it used to talk to client machines on the network. The [[Banyan (company)|Banyan]] company based the VINES operating system on [[Unix]], and the network protocols on the archetypical [[Xerox XNS]] stack. VINES formed one of a group of XNS-based systems which also included [[Novell NetWare]] and [[ARCNET]]; like most of these earlier products, it has since disappeared from the market, Banyan along with it. |
|||
{{refimprove|date=June 2016}} |
|||
{{Infobox OS |
|||
| name = Banyan VINES |
|||
| developer = Banyan Systems |
|||
| programmed in = [[C (programming language)|C]] |
|||
| family = [[Unix]] ([[SVR3.2]]) |
|||
| source model = [[Closed-source]] |
|||
| supported platforms = [[x86]] |
|||
| kernel type = [[Monolithic kernel|Monolithic]] |
|||
}} |
|||
'''Banyan VINES''' is a discontinued [[network operating system]] developed by [[Banyan Systems]] for computers running [[AT&T]]'s [[UNIX System V]]. |
|||
''VINES'' is an acronym for ''Virtual Integrated NEtwork Service''. Like [[Novell NetWare]], VINES's network services are based on the [[Xerox XNS]] [[Protocol stack|stack]]. |
|||
[[James Allchin]], who has since worked as Group Vice President for Platforms at [[Microsoft Corporation]] until his retirement at January 30th 2007, worked as the chief architect of Banyan VINES. |
|||
[[James Allchin]], who later worked as Group Vice President for Platforms at [[Microsoft]] until his retirement on January 30, 2007, was the chief architect of Banyan VINES. |
|||
VINES ran on a low-level protocol known as '''VIP''', the ''VINES Internetwork Protocol'': essentially identical to the lower layers of XNS. Addresses consisted of a 32-bit address and a 16-bit subnet, which mapped onto the 48-bit [[Ethernet]] address in order to route to machines. This meant that, like other XNS-based systems, VINES could only support a two-level internet. |
|||
{{Infobox networking protocol |
|||
However, a set of routing algorithms set VINES apart from other XNS systems at this level. The key differentiator, '''ARP''' (''Address Resolution Protocol''), allowed VINES clients to automatically set up their own network addresses. When a client first booted up it broadcast a request on the subnet asking for servers, which would respond with suggested addresses. The client would use the first to respond, although the servers could hand off "better" [[routing]] instructions to the client if the network changed. The overall concept very much resembled [[AppleTalk]]'s AARP system, with the exception that VINES required at least one server, whereas AARP functioned completely "headlessly". Like AARP, VINES required an inherently "chatty" network, sending updates about the status of clients to other servers on the [[internetwork]]. |
|||
| title = VINES |
|||
| logo = |
|||
| logo alt = |
|||
| image = |
|||
| image alt = |
|||
| caption = |
|||
| is stack = yes |
|||
| purpose = [[LAN]] |
|||
| developer = [[Banyan Systems]] |
|||
| date = {{Start date and age| 1984 | | }}<!--Fill in: Year (4 digits), month and day (2 digits)--> |
|||
| based on = [[Xerox Network Services|XNS]] |
|||
| influenced = |
|||
| osilayer = 3 to 7 |
|||
| ports = |
|||
| rfcs = |
|||
| hardware = [[Ethernet]], others |
|||
}} |
|||
== VINES technology == |
|||
VINES ran on a low-level protocol known as ''VIP''—the ''VINES Internetwork Protocol''—that was essentially identical to the lower layers of the [[Xerox Network Systems]] (XNS) protocols. Addresses consist of a 32-bit address and a 16-bit [[subnet]] that map to the 48-bit [[Ethernet]] address to route to machines. This means that, like other XNS-based systems, VINES can only support a two-level internet. |
|||
A set of [[routing algorithm]]s, however, set VINES apart from other XNS systems at this level. The key differentiator, ''ARP'' (''Address Resolution Protocol''), allowed VINES clients to automatically set up their own network addresses. When a client first boots up, it broadcast a request on the subnet asking for servers, which responds with suggested addresses. The client used the first to respond, although the servers could hand off "better" [[routing]] instructions to the client if the network changed. The overall concept resembled [[AppleTalk]]'s AARP system, with the exception that VINES required at least one server, whereas AARP functioned as [[peer-to-peer]]. Like AARP, VINES required an inherently "chatty" network, sending updates about the status of clients to other servers on the [[internetwork]]. |
|||
Rounding out its lower-level system, VINES used '''RTP''' (the ''Routing Table Protocol''), a low-overhead message system for passing around information about changes to the routing, and ARP to determine the address of other nodes on the system. These closely resembled the similar systems used in other XNS-based protocols. VINES also included '''ICP''' (the ''Internet Control Protocol''), which it used to pass error-messages and metrics. |
|||
Rounding out its lower-level system, VINES used ''RTP'' (the ''Routing Table Protocol''), a low-overhead message system for passing around information about changes to the routing, and ARP to determine the address of other nodes on the system. These closely resembled the similar systems used in other XNS-based protocols. VINES also included ''ICP'' (the ''Internet Control Protocol''), which it used to pass error-messages and metrics. |
|||
At the middle layer level, VINES used fairly standard software. The '''unreliable datagram service''' and '''data-stream service''' operated essentially identically to [[User Datagram Protocol|UDP]] and [[Transmission Control Protocol|TCP]] on top of [[Internet Protocol|IP]]. However VINES also added a '''reliable message service''' as well, a sort of hybrid of the two that offered guaranteed delivery of a single packet. |
|||
At the middle layer level, VINES used fairly standard software. The ''unreliable datagram service'' and ''data-stream service'' operated essentially identically to [[User Datagram Protocol|UDP]] and [[Transmission Control Protocol|TCP]] on top of [[Internet Protocol|IP]]. VINES added a ''reliable message service'' as well, a hybrid of the two that offered guaranteed delivery of single packets. |
|||
At the topmost layer, VINES provided the standard file and print services, as well as the unique '''StreetTalk''', likely the first truly practical globally-consistent [[name Service | name-service]] for an entire internetwork. Using a globally distributed, partially replicated database, StreetTalk could meld multiple widely-separated networks into a single network that allowed seamless resource-sharing. It accomplished this through its rigidly hierarchical naming-scheme; entries in the directory always had the form ''item''@''group''@''organization''. This applied to user accounts as well as to resources like [[Computer printer|printer]]s and [[file server]]s. |
|||
Banyan offered customers [[TCP/IP]] as an extra cost option for owners of standard Vines servers. This extra charge for TCP/IP on VINES servers continued long after TCP/IP server availability had become commoditized. |
|||
VINES client-software ran on most PC-based operating systems, including [[MS-DOS]] and earlier versions of [[Microsoft Windows]]. It was fairly light-weight on the client, and hence remained in use during the later half of the 1990s, when many machines not up to the task of running other networking stacks then in widespread use. This occurred on the server side as well, as VINES generally offered good performance even from mediocre hardware. |
|||
At the topmost layer, VINES provided the standard file and print services, as well as the unique ''StreetTalk'', a globally consistent [[name Service|name service]]. Banyan has a version of StreetTalk that ran natively on an NT server.<ref>{{Cite book |last=Rajgopal |first=Raj |url=https://books.google.com/books?id=KC1KDwAAQBAJ&dq=StreetTalk&pg=PT676 |title=Handbook of Heterogeneous Networking |date=2018-01-31 |publisher=CRC Press |isbn=978-1-351-08952-4 |language=en}}</ref> Using a globally distributed, partially replicated database, StreetTalk could meld multiple widely separated networks into a single network that allowed seamless resource-sharing. It accomplished this through its rigidly hierarchical naming-scheme; entries in the directory took the form ''item''@''group''@''organization'' (similar to the naming format used in the XNS Clearinghouse directory service: ''item'':''group'':''organization''). This applied to user accounts as well as to resources like [[Printer (computing)|printers]] and [[file server]]s. |
|||
By the late 1990s this performance edge became irrelevant and then disappeared, as VINES could use a maximum of only 96 [[Megabyte|MB]] of [[RAM]] and a single processor due to its aging [[UNIX System V|SVR3]] underpinnings, preventing it from taking advantage of newer hardware. VINES sales rapidly dried up, both due to these problems, as well as the rapid rise of [[Windows NT]]. Banyan increasingly turned to StreetTalk as a differentiator, eventually porting it to NT as a stand-alone product, and offering it as an interface to [[Lightweight Directory Access Protocol|LDAP]] systems. |
|||
== Protocol stack == |
|||
Banyan eventually re-formed in 1999 as '''ePresence''', a general [[Internet]] services company. This didn't fare very well either, and after a series of failed ventures it finally sold its services division to [[Unisys]] in late 2003 and liquidated its remaining holdings in their Switchboard.com subsidiary. |
|||
{| border="0" |
|||
| OSI layer |
|||
| colspan="6" align="center" | VINES Protocol Stack |
|||
|----- |
|||
| align="center" bgcolor="#FFFF99" | 7 |
|||
| align="center" bgcolor="#9999FF" | File Services |
|||
| align="center" bgcolor="#9999FF" | Print Services |
|||
| colspan="2" align="center" bgcolor="#9999FF" | StreetTalk (directory service) |
|||
| colspan="2" align="center" bgcolor="#9999FF" | other Services |
|||
|----- |
|||
| align="center" bgcolor="#FFFF99" | 6 |
|||
| rowspan="2" colspan="6" align="center" bgcolor="#9999FF" | Remote Procedure Calls (RPC) |
|||
|----- |
|||
| align="center" bgcolor="#FFFF99" | 5 |
|||
| || || || || || |
|||
|----- |
|||
| align="center" bgcolor="#FFFF99" | 4 |
|||
| colspan="3" align="center" bgcolor="#9999FF" | InterProcess Communications (IPC)<br>''Datagram'' |
|||
| colspan="3" align="center" bgcolor="#9999FF" | Sequenced Packet Protocol (SPP)<br>''Stream'' |
|||
|----- |
|||
| align="center" bgcolor="#FFFF99" | 3 |
|||
| colspan="4" align="center" bgcolor="#9999FF" | VINES Internetwork Protocol (VIP) |
|||
| colspan="2" align="center" bgcolor="#9999FF" | [[Address Resolution Protocol]] (ARP)<br>Routing Table Protocol (RTP)<br>Internet Control Protocol (ICP) |
|||
|----- |
|||
| align="center" bgcolor="#FFFF99" | 2 |
|||
| rowspan="2" colspan="6" align="center" bgcolor="#CCCCCC" | Media Access Protocols:<br>[[HDLC]], [[X.25]], [[Token Ring]], [[Ethernet]] |
|||
|----- |
|||
| align="center" bgcolor="#FFFF99" | 1 |
|||
| |
|||
|} |
|||
== VINES client software == |
|||
{{unreferenced|date=December 2006}} |
|||
VINES client software ran on most earlier PC-based operating systems, including [[MS-DOS]] and earlier versions of [[Microsoft Windows]]. It was lightweight on the client, and hence remained in use during the latter half of the 1990s on many older machines that could not run other networking stacks. This occurred on the server side as well, as VINES generally offered good performance, even from mediocre hardware. |
|||
== Initial market release == |
|||
[[Category:Operating systems]] |
|||
With StreetTalk's inherent low bandwidth requirements, global companies and governments that grasped the advantages of worldwide [[directory services]] seamlessly spanning multiple time zones recognized VINE's technological edge. Users included gas and oil companies, power companies, public utilities—and U.S. Government agencies including the State Department, [[United States Department of the Treasury|Treasury Department]], [[United States Department of Agriculture|Department of Agriculture]], [[Department of Health and Human Services]], and [[Department of Defense]]. |
|||
The [[U.S. State Department]] was an early adopter of the VINES technology. Able to take advantage of the then high-speed [[Modem#56k|56k modems]] for telephonic connectivity of the developed world to the limited telephone modem speeds of 300 [[baud]] over bad analog telephone systems in developing countries, VINES linked embassies around the world. VINES also features built-in point-to-point and group chat capability that was useful for basic communication over secure lines. |
|||
[[de:Banyan Vines]] |
|||
[[id:Banyan VINES]] |
|||
== Defense Department adoption == |
|||
By the late 1980s, the [[US Marine Corps]] was searching for simple, off-the-shelf worldwide network connectivity with rich built-in email, file, and print features. By 1988, the Marine Corps had standardized on VINES<ref>[https://books.google.com/books?id=1T0EAAAAMBAJ&q=banyan+vines+marines%22The&pg=PA76 U.S. Marines' Network-Linked War Units"], 14 Oct 1991, p576, InfoWorld</ref> as both its [[garrison]] (base) and forward-deployed ground-based battlefield email-centric [[network operating system]]. |
|||
Using both ground-based secure radio channels and satellite and military tactical phone switches, the Marine Corps was ready for its first big test of VINES: the [[1990-1991 Gulf War]]. Units were able to seamlessly coordinate ground, naval, and air strikes across military boundaries by using the chat function to pass target lists and adjust naval gun fire on the fly. Ground fire support coordination agencies used VINES up and down command channels—from Battalion-to-Regiment through Division-to-Corps and Squadron-to-Group to Aircraft Wing-to-Corps, as well as in peer-to-peer unit communication. {{Citation needed|date=August 2009}} |
|||
== VINES competitors == |
|||
{{Unreferenced section|date=July 2022}} |
|||
[[3Com]]'s journey into network operating system development began in the late 1970s. In 1979, they introduced their first network operating system, called 3+Share. It allowed multiple users to access files and resources on a shared server. However, it wasn't until 1982 that 3Com released 3Server, which was a significant step forward. |
|||
3Server was designed to work with 3Com's Ethernet hardware and was aimed at creating [[local area network]]s (LANs). It provided file and print sharing capabilities, enabling multiple computers to access common resources like printers and files. It operated on the XNS (Xerox Network Systems) protocol suite. |
|||
Over the years, 3Com continued to refine and improve its network operating systems. In 1985, they introduced 3+Open, which added support for third-party hardware. 3+Open was a significant advancement in 3Com's network operating system lineup. Introduced in 1985, it expanded on the capabilities of their previous offerings by providing support for third-party hardware and software. This allowed 3+Open to work with a wider range of network devices and systems, increasing its compatibility and appeal to a broader audience. |
|||
3Com's contribution to Microsoft's network and server software capabilities is closely tied to their collaboration on the development of [[LAN Manager]]. LAN Manager was Microsoft's networking software that aimed to provide file and print services for PCs connected in a network. In the late 1980s, Microsoft partnered with 3Com to integrate 3+Open's networking capabilities into LAN Manager. |
|||
This collaboration led to the creation of LAN Manager 2.0, which was released in 1989. This version of LAN Manager incorporated technologies from both Microsoft and 3Com, resulting in improved networking capabilities and compatibility. It enabled Microsoft to strengthen its networking offerings, making it a more competitive player in the network operating system space. |
|||
Microsoft's experience with LAN Manager laid the foundation for their subsequent development of [[Windows NT]] and [[Windows Server]] operating systems. The knowledge and technologies gained from working with 3Com's networking solutions contributed to the evolution of Microsoft's network and server software capabilities, helping them become a dominant force in the networking and server industry. |
|||
For a decade, Banyan's OS competitors, [[Novell]] and Microsoft, dismissed the utility of [[directory services]]. Consequently, VINES dominated what came to be called the "directory services" space from 1985 to 1995. While seeming to ignore VINES, Novell and eventually Microsoft—companies with a flat server or domain-based network model—came to realize the strategic value of directory services. With little warning, Novell went from playing down the value of directory services to announcing its own: [[NetWare Directory Services]] (NDS). Eventually, Novell changed ''NDS'' to mean Novell Directory Services, and then renamed that to eDirectory.<ref name="ogletree2004">{{Cite book |last=Ogletree |first=Terry William |url=https://books.google.com/books?id=ZHXeT01OSXcC&dq=Novell+to+NetWare+Directory+Services+(NDS).+Novell+changed+NDS+to+mean+Novell+Directory+Services,+and+then+renamed+that+to+eDirectory.&pg=RA1-PA624 |title=Upgrading and Repairing Networks |date=2004 |publisher=Que Publishing |isbn=978-0-7897-2817-3 |language=en}}</ref> |
|||
For [[Windows 2000]] however, Microsoft included [[Active Directory]], an LDAP directory service based on the directory from its [[Microsoft Exchange Server|Exchange mail server]].<ref name="ogletree2004" /> While VINES is limited to a three-part name, user.company.org, like Novell's NDS structure, Active Directory is not bound by such a naming convention. Active Directory features an additional capability that both NDS and VINES lack, its "forest and trees" organizational model. The combination of better architecture and with marketing from a company the size of Microsoft doomed StreetTalk, VINES as an OS, and finally Banyan itself. |
|||
== Decline == |
|||
By the late 1990s, VINES's once-touted StreetTalk Services's non-flat, non-domain model had lost ground to newer technology, despite its built-in messaging, efficiency and onetime performance edge. Banyan was unable to market its product far beyond its initial base of multi-national and government entities. |
|||
The company lost ground in the networking market, and VINES sales dropped. Banyan increasingly turned to StreetTalk as a differentiator, eventually porting it to NT as a stand-alone product and offering it as an interface to [[Lightweight Directory Access Protocol|LDAP]] systems. {{Citation needed|date=August 2009}} |
|||
Banyan continued to operate a closed OS. This required hardware manufacturers to submit hardware and driver requirements so that Banyan could write drivers for each peripheral. When more [[Open systems architecture|open systems]] with published APIs began to appear, Banyan did not alter their model. This made it difficult for client-side support to handle the explosive growth in, for example, printers. As competitors began to adopt some of VINES's outstanding wide area networking protocols and services, manufacturers were less inclined to send a unit to Banyan for VINES specific drivers when competitors allowed them to write their own. |
|||
Dropping the Banyan brand for ''ePresence'' in 1999, as a general [[Internet]] services company, the firm sold its services division to [[Unisys]] in late 2003 and liquidated its remaining holdings in its Switchboard.com subsidiary. |
|||
== Version history == |
|||
*1984: Banyan VINES 1.0 |
|||
*1989: Banyan VINES 2.1 |
|||
*1990: Banyan VINES 3.0 |
|||
*1991: Banyan VINES 4.11 |
|||
*1992: Banyan VINES 5.0 |
|||
*1994: Banyan VINES 5.50 |
|||
*1997: Banyan VINES 7.0 |
|||
== References == |
|||
{{Reflist}} |
|||
== Resource == |
|||
* [http://banyan-vines.bamertal.com Banyan VINES] at Bamertal Publishing |
|||
* [http://coldtail.com/wiki/index.php?search=Banyan Banyan VINES] at Coldtail.com |
|||
{{Network operating systems}} |
|||
{{DEFAULTSORT:Banyan Vines}} |
|||
[[Category:1984 software]] |
|||
[[Category:Directory services]] |
|||
[[Category:Discontinued operating systems]] |
|||
[[Category:Network operating systems]] |
|||
[[Category:UNIX System V]] |
|||
[[Category:X86 operating systems]] |
|||
[[Category:XNS based protocols]] |
Latest revision as of 21:02, 4 December 2024
This article needs additional citations for verification. (June 2016) |
Developer | Banyan Systems |
---|---|
Written in | C |
OS family | Unix (SVR3.2) |
Source model | Closed-source |
Platforms | x86 |
Kernel type | Monolithic |
Banyan VINES is a discontinued network operating system developed by Banyan Systems for computers running AT&T's UNIX System V.
VINES is an acronym for Virtual Integrated NEtwork Service. Like Novell NetWare, VINES's network services are based on the Xerox XNS stack.
James Allchin, who later worked as Group Vice President for Platforms at Microsoft until his retirement on January 30, 2007, was the chief architect of Banyan VINES.
Protocol stack | |
Purpose | LAN |
---|---|
Developer(s) | Banyan Systems |
Introduction | 1984 |
Based on | XNS |
OSI layer | 3 to 7 |
Hardware | Ethernet, others |
VINES technology
[edit]VINES ran on a low-level protocol known as VIP—the VINES Internetwork Protocol—that was essentially identical to the lower layers of the Xerox Network Systems (XNS) protocols. Addresses consist of a 32-bit address and a 16-bit subnet that map to the 48-bit Ethernet address to route to machines. This means that, like other XNS-based systems, VINES can only support a two-level internet.
A set of routing algorithms, however, set VINES apart from other XNS systems at this level. The key differentiator, ARP (Address Resolution Protocol), allowed VINES clients to automatically set up their own network addresses. When a client first boots up, it broadcast a request on the subnet asking for servers, which responds with suggested addresses. The client used the first to respond, although the servers could hand off "better" routing instructions to the client if the network changed. The overall concept resembled AppleTalk's AARP system, with the exception that VINES required at least one server, whereas AARP functioned as peer-to-peer. Like AARP, VINES required an inherently "chatty" network, sending updates about the status of clients to other servers on the internetwork.
Rounding out its lower-level system, VINES used RTP (the Routing Table Protocol), a low-overhead message system for passing around information about changes to the routing, and ARP to determine the address of other nodes on the system. These closely resembled the similar systems used in other XNS-based protocols. VINES also included ICP (the Internet Control Protocol), which it used to pass error-messages and metrics.
At the middle layer level, VINES used fairly standard software. The unreliable datagram service and data-stream service operated essentially identically to UDP and TCP on top of IP. VINES added a reliable message service as well, a hybrid of the two that offered guaranteed delivery of single packets.
Banyan offered customers TCP/IP as an extra cost option for owners of standard Vines servers. This extra charge for TCP/IP on VINES servers continued long after TCP/IP server availability had become commoditized.
At the topmost layer, VINES provided the standard file and print services, as well as the unique StreetTalk, a globally consistent name service. Banyan has a version of StreetTalk that ran natively on an NT server.[1] Using a globally distributed, partially replicated database, StreetTalk could meld multiple widely separated networks into a single network that allowed seamless resource-sharing. It accomplished this through its rigidly hierarchical naming-scheme; entries in the directory took the form item@group@organization (similar to the naming format used in the XNS Clearinghouse directory service: item:group:organization). This applied to user accounts as well as to resources like printers and file servers.
Protocol stack
[edit]OSI layer | VINES Protocol Stack | |||||
7 | File Services | Print Services | StreetTalk (directory service) | other Services | ||
6 | Remote Procedure Calls (RPC) | |||||
5 | ||||||
4 | InterProcess Communications (IPC) Datagram |
Sequenced Packet Protocol (SPP) Stream | ||||
3 | VINES Internetwork Protocol (VIP) | Address Resolution Protocol (ARP) Routing Table Protocol (RTP) Internet Control Protocol (ICP) | ||||
2 | Media Access Protocols: HDLC, X.25, Token Ring, Ethernet | |||||
1 |
VINES client software
[edit]VINES client software ran on most earlier PC-based operating systems, including MS-DOS and earlier versions of Microsoft Windows. It was lightweight on the client, and hence remained in use during the latter half of the 1990s on many older machines that could not run other networking stacks. This occurred on the server side as well, as VINES generally offered good performance, even from mediocre hardware.
Initial market release
[edit]With StreetTalk's inherent low bandwidth requirements, global companies and governments that grasped the advantages of worldwide directory services seamlessly spanning multiple time zones recognized VINE's technological edge. Users included gas and oil companies, power companies, public utilities—and U.S. Government agencies including the State Department, Treasury Department, Department of Agriculture, Department of Health and Human Services, and Department of Defense.
The U.S. State Department was an early adopter of the VINES technology. Able to take advantage of the then high-speed 56k modems for telephonic connectivity of the developed world to the limited telephone modem speeds of 300 baud over bad analog telephone systems in developing countries, VINES linked embassies around the world. VINES also features built-in point-to-point and group chat capability that was useful for basic communication over secure lines.
Defense Department adoption
[edit]By the late 1980s, the US Marine Corps was searching for simple, off-the-shelf worldwide network connectivity with rich built-in email, file, and print features. By 1988, the Marine Corps had standardized on VINES[2] as both its garrison (base) and forward-deployed ground-based battlefield email-centric network operating system.
Using both ground-based secure radio channels and satellite and military tactical phone switches, the Marine Corps was ready for its first big test of VINES: the 1990-1991 Gulf War. Units were able to seamlessly coordinate ground, naval, and air strikes across military boundaries by using the chat function to pass target lists and adjust naval gun fire on the fly. Ground fire support coordination agencies used VINES up and down command channels—from Battalion-to-Regiment through Division-to-Corps and Squadron-to-Group to Aircraft Wing-to-Corps, as well as in peer-to-peer unit communication. [citation needed]
VINES competitors
[edit]3Com's journey into network operating system development began in the late 1970s. In 1979, they introduced their first network operating system, called 3+Share. It allowed multiple users to access files and resources on a shared server. However, it wasn't until 1982 that 3Com released 3Server, which was a significant step forward.
3Server was designed to work with 3Com's Ethernet hardware and was aimed at creating local area networks (LANs). It provided file and print sharing capabilities, enabling multiple computers to access common resources like printers and files. It operated on the XNS (Xerox Network Systems) protocol suite.
Over the years, 3Com continued to refine and improve its network operating systems. In 1985, they introduced 3+Open, which added support for third-party hardware. 3+Open was a significant advancement in 3Com's network operating system lineup. Introduced in 1985, it expanded on the capabilities of their previous offerings by providing support for third-party hardware and software. This allowed 3+Open to work with a wider range of network devices and systems, increasing its compatibility and appeal to a broader audience.
3Com's contribution to Microsoft's network and server software capabilities is closely tied to their collaboration on the development of LAN Manager. LAN Manager was Microsoft's networking software that aimed to provide file and print services for PCs connected in a network. In the late 1980s, Microsoft partnered with 3Com to integrate 3+Open's networking capabilities into LAN Manager.
This collaboration led to the creation of LAN Manager 2.0, which was released in 1989. This version of LAN Manager incorporated technologies from both Microsoft and 3Com, resulting in improved networking capabilities and compatibility. It enabled Microsoft to strengthen its networking offerings, making it a more competitive player in the network operating system space.
Microsoft's experience with LAN Manager laid the foundation for their subsequent development of Windows NT and Windows Server operating systems. The knowledge and technologies gained from working with 3Com's networking solutions contributed to the evolution of Microsoft's network and server software capabilities, helping them become a dominant force in the networking and server industry.
For a decade, Banyan's OS competitors, Novell and Microsoft, dismissed the utility of directory services. Consequently, VINES dominated what came to be called the "directory services" space from 1985 to 1995. While seeming to ignore VINES, Novell and eventually Microsoft—companies with a flat server or domain-based network model—came to realize the strategic value of directory services. With little warning, Novell went from playing down the value of directory services to announcing its own: NetWare Directory Services (NDS). Eventually, Novell changed NDS to mean Novell Directory Services, and then renamed that to eDirectory.[3]
For Windows 2000 however, Microsoft included Active Directory, an LDAP directory service based on the directory from its Exchange mail server.[3] While VINES is limited to a three-part name, user.company.org, like Novell's NDS structure, Active Directory is not bound by such a naming convention. Active Directory features an additional capability that both NDS and VINES lack, its "forest and trees" organizational model. The combination of better architecture and with marketing from a company the size of Microsoft doomed StreetTalk, VINES as an OS, and finally Banyan itself.
Decline
[edit]By the late 1990s, VINES's once-touted StreetTalk Services's non-flat, non-domain model had lost ground to newer technology, despite its built-in messaging, efficiency and onetime performance edge. Banyan was unable to market its product far beyond its initial base of multi-national and government entities.
The company lost ground in the networking market, and VINES sales dropped. Banyan increasingly turned to StreetTalk as a differentiator, eventually porting it to NT as a stand-alone product and offering it as an interface to LDAP systems. [citation needed]
Banyan continued to operate a closed OS. This required hardware manufacturers to submit hardware and driver requirements so that Banyan could write drivers for each peripheral. When more open systems with published APIs began to appear, Banyan did not alter their model. This made it difficult for client-side support to handle the explosive growth in, for example, printers. As competitors began to adopt some of VINES's outstanding wide area networking protocols and services, manufacturers were less inclined to send a unit to Banyan for VINES specific drivers when competitors allowed them to write their own.
Dropping the Banyan brand for ePresence in 1999, as a general Internet services company, the firm sold its services division to Unisys in late 2003 and liquidated its remaining holdings in its Switchboard.com subsidiary.
Version history
[edit]- 1984: Banyan VINES 1.0
- 1989: Banyan VINES 2.1
- 1990: Banyan VINES 3.0
- 1991: Banyan VINES 4.11
- 1992: Banyan VINES 5.0
- 1994: Banyan VINES 5.50
- 1997: Banyan VINES 7.0
References
[edit]- ^ Rajgopal, Raj (2018-01-31). Handbook of Heterogeneous Networking. CRC Press. ISBN 978-1-351-08952-4.
- ^ U.S. Marines' Network-Linked War Units", 14 Oct 1991, p576, InfoWorld
- ^ a b Ogletree, Terry William (2004). Upgrading and Repairing Networks. Que Publishing. ISBN 978-0-7897-2817-3.
Resource
[edit]- Banyan VINES at Bamertal Publishing
- Banyan VINES at Coldtail.com