Talk:Internetwork Packet Exchange
|WikiProject Computing / Networking||(Rated Start-class, Low-importance)|
Because of what appeared in the IPX/SPX page to be an inconsistency, I have looked around a little for IPX/SPX information and found some conflicting references. It seems like what we have about NetWare protocols and their corresponding OSI layers is probably wrong. IPX does do port multiplexing itself and so is largely also a layer 4 protocol, and SPX only appears to do a subset of TCP's work, so our comparisons to TCP/IP are misleading if not significantly wrong.
I plan to do more reading but would really appreciate input from someone who knows more. --Heywood 00:48, 12 July 2006 (UTC)
I'm not sure what your problem with that is. It's the base protocol of IPX/SPX, running directly over the link layer, and as such it's the network layer. SPX runs on it just as TCP runs on IP. However, IPX doesn't need a transport layer running over it; unadorned, it sends datagram packets which can be used without the aid of an additional transport layer. So just as both articles state, it is analagous to both IP and UDP, where SPX is analagous to TCP. There really isn't a dispute here, so I'll remove the tags. Kundor 22:32, 17 September 2006 (UTC)
Advantage over TCP/IP?
- No. Its only reason for existence is that, at the time it was originally developed and deployed, the correct protocol choice was still unclear. (Recall that this was the heyday of both OSI and ATM standards development, both of which at various times seemed to have legitimate claim to being "the protocol of the future".) Novell took a well-known, simple protocol suite with multiple pre-existing implementations, XNS, and modified it slightly to suit their more limited goals. In hindsight, we could wish that they had chosen the Internet protocol suite instead, but at the time it was a sensible decision -- and Novell was far from the only company to do so. 188.8.131.52 05:52, 1 Jan 2005 (UTC)
- I disagree. It's reason for existence is that, at the time it was originally developed and deployed, there was no such thing as a single "correct" protocol choice. The mid to late 80s (and into the early 90s) were the age of multi-protocol networking. When did a TCP stack finally ship with Windows? Not until 1994 with WfW 3.11, and even in Win95 TCP was not a default; IPX was. Every computer and OS vendor had their own protocols; that's how the world was then. It is also incorrect to say there are "no advantages" to IPX. It is more correct to say that the advantages are not enough to outweigh the disadvantages today. IPX has a larger address space: 48 bits (or is it 64?) instead of 32 bits in IPv4. IPX addresses incorporate the local MAC address: there is no "address assignment" like with IPv4. There is no such thing as BootP or DHCP in IPX, because none is needed. One of the reasons DHCP was invented from BootP was because IPv4 couldn't do what IPX did: allow "plug-and-go" network addressing. Guess what feature was added in IPv6? Including the MAC address in the internetwork address, just like IPX. Other things declared "bad" about IPX are bad about IP also, and most of the improvements made to the TCP/IP world in the last 10 years could have been made to the IPX world also. A good example is RIP broadcasting. It has the same problems in IPv4 as in IPX. OSPF was invented to fix it in the IPv4 world, and Novell came up with a similar link-state routing protocol for IPX also. The real advantage of TCP/IP is vendor-independent open standards and interoperability, not raw technical superiority. IP may have that now, which is still debatable with some parts of IPv4, but it didn't at the time it competed with IPX. --Amillar 09:06, 2 Jan 2005 (UTC)
READING NEEDS TO BE DONE
I'm not going to try and take everyone to school so I'm going to tell you where to get the info needed on this. There is a text book called Networking Concepts written by James L. Antonakos and Kenneth C. Mansfield Jr. and, for that reason, I don't want to use their work and get Wikipedia in trouble. But I will say this: they're NOT the same and don't help each other either. IPX/SPX protocol and TCP/IP protocol are different, similar, but different. Comparing them should only be done in the sense of showing their similarities. Any further than that and you're just giving your opinion.
It turns out there is another meaning for IPX. It's a rating system for levels of waterproofing, related to IEC 60529.
i agree. i actually got to this page looking for information on the waterproof standard. maybe we don't need a disambiguation page, but one of those one-liners. --21:53, 27 June 2006 (UTC)
Support of IPX....
It says the following systems do not support the protocol .... Does that mean that every other os supports the protocol? Needs to be cleared up. Unless it means what it says, that every other system supports IPX Maybe saying the following systems are confirmed as not supporting the protocol. IMBlackMath (talk) 08:22, 28 April 2009 (UTC)
OSI vs TCP/IP
Should the article really reference which layer in the osi model it's in when it shows a box of the tcp/ip model on the right? I don't mind which but i'd prefer to reference and show only ONE. 184.108.40.206 (talk) 04:53, 15 December 2010 (UTC)
IPX doesn't scale well?
Radia Perlman disagrees in her book "Interconnections":
9.6.2 Ugly Rumors about IPX People believe, for some reason, that IPX is "unroutable", "doesn't work on WANs" or "doesn't scale." IPX is actually a wonderful network layer protocol, better than IP in almost every way (except for little things such as having a hop count that increments rather than decrements). Why do many people believe bad things about it? The answer is that there is a germ of truth in what they are saying, but it has nothing to do with IPX. IPX is, as I said, quite wonderful: it has large addresses, it is autoconfiguring, it is simple to implement, and it requires low overhead. But unfortunately, IPX hangs out with some unsavory company, such as SPX, a protocol just like TCP but with a window size of 1;...... — Preceding unsigned comment added by 220.127.116.11 (talk) 08:38, 23 August 2012 (UTC)
- Thought at first that it related to the old "802.3" Novell framing vs proper 802.2 framing but it doesn't seem to be related. "802.3" isn't really indicated at all which is the main problem. EtherType 0x8137 is usually mentioned as "old" and that may be all there is to it. Zac67 (talk) 19:41, 16 January 2013 (UTC)
- 0x8137 shows up more frequently in searches than 0x8138 but I have not found any refs that explain why there are two EtherTypes. -—Kvng 14:44, 17 January 2013 (UTC)
Could it be BigEndian vs LittleEndian? (I too am unable to find any documentation, but I also find no reference for distinguishing the byte order) — Preceding unsigned comment added by Ntrcessor (talk • contribs) 15:11, 6 February 2015 (UTC)
- As it is, EtherTypes 0x8137 & 0x8138 are assigned to Novell. Since there's no Novell doc any more, we'll probably never know for sure. However, I found this an interesting read (search Google groups for "novell.com 1993sep17"): 0x8137 indicate IPX over Ethernet_II (which probably only few people ever used) but we already have that. Designing Large Scale LANs by Kevin Dooley (2002) says "Type 8137 designates an older version of IPX that is not widely used anymore, while 8138 is the most typical for modern IPX installations." -- Zac67 (talk) 18:29, 6 February 2015 (UTC)