Talk:Computer network

Archives

Archive 1: Old Article on 5-15-07

Archive 2: Talk Archive1

Just some comments on the intentions of the article:

• It is meant as an overview article forwarding people to the relevant articles. As such it is IMHO already quite long. So major extensions (and maybe also smaller ones) should probably go into an new, linked article.
• I started with the applications and not the protocols because I think it is more natural for non-CS people to learn what is done with networks, what that means for the qualities networks must have to finally stop to understand things when the technicalities are explained.
• Any ideas on figures/pictures to show?

--Markus Baumeister 18:33, 11 March 2007 (CDT)

I added a link to Network topology, and threw some rough diagrams up of a bus network and ring network. There's a lot more to add though... --Eric M Gearhart 03:12, 1 April 2007 (CDT)

I just threw 'Category:CZ Live' on this article... it was created from scratch, right? --Eric M Gearhart 10:29, 2 April 2007 (CDT)

Yes. BTW, I moved the topology section to after the QoS bullet as otherwise the "How 'guaranteed' are the above attributes" of QoS doesn't work anymore. Topology is not influenced by QoS. And then there is the more general problem how to distinguish whether topology is a "feature" (I only thought about measurable things for that) or a "categorization". Markus Baumeister 15:15, 2 April 2007 (CDT)

Ugh so much to do on here it's friggin crazy! I will try to improve this and the topology article in the future --Eric M Gearhart 11:40, 8 April 2007 (CDT)

history of networking

Just as the history of computing needs it own article, I believe that we could use a history of networking article. If I had time, I could probably write it (with help). There is a dramatic story there, starting with how (and why) DARPA funded the original research, then including widespread academic and industry participation, the earliest networks, the early network marketplace, and then its evolution over time into what we have now. This article could then be the springboard off to more specific articles on specific types of networks, or in general to the history of networking.Pat Palmer 03:59, 6 May 2007 (CDT)

There is a stub for internet which would need to fit into the overall framework of articles somehow. The internet is what survived out of all the fierce competition of the earlier networks.Pat Palmer 04:02, 6 May 2007 (CDT)

needs overhaul

There is a lot of good information in this article, but I think the article is targeted too much for people who already know about computer networks. It uses a lot of jargon without first introducing the jargon. I think it's going to need a major overhaul. We don't want to be a textbook, which would happen if we go too deep, but we do need some technical details. I'd like to see the article start up more "gently" for non-geek readers, and then warm up later to satisfy the techno-heads among us.Pat Palmer 22:48, 12 May 2007 (CDT)

It's also really vague despite all the jargon. Did the bulk of this come over from Wikipedia by any chance? I've implemented networks, and taught networks, and I know we can do better by this topic. But it's a hard topic, because it's all in the imagination. Needs diagrams to illustrate simple concepts, etc. I'll try to come back to it another time. Too tired tonight.Pat Palmer 22:51, 12 May 2007 (CDT)

Introductory section - suggest a complete rewrite

The introductory section seems a bit strained to me. For example, the distinction between computer networks and communication networks doesn't fit at all with common usage. It is more accurate to say that at the implementation level, computer networks consist of general purpose computers and specialized devices (such as routers, bridges, etc.) interconnected by physical or wireless media. The emphasis on computer in computer network reflects an emphasis on their functional characteristics, rather than design strategy, and a recognition that like cables and telephone lines, routers are essentially part of the network infrastructure. I'd like to have a go at rewriting this entire section. Greg Woodhouse 13:56, 14 May 2007 (CDT)

Agree completely. In fact, I would probably archive the entire article where I could get at it and start over. However, I do not have time. There are good nuggets, but a lay reader would not be able to see the forest for the trees, as they say. A big missing thing is any explanation, to lay readers, about what a "layer" is. This is crying out for some simple diagrams, and a writing style that assumes no prior knowledge of geeky network terms, takes the time and patience to built the concepts, and then branches off to (sub)articles of increasing detail about particular items. Pat Palmer 14:17, 14 May 2007 (CDT)

BAN vs. PAN

I'm not at all sure whether body area network (BAN) needs to be included in the article, but the example given (a wireless headset) is an example of a personal area network (PAN). Nanotechnology is not my area, but my sense is that the term BAN is meant to apply to networks of devices within the human body. Greg Woodhouse 14:15, 14 May 2007 (CDT)

No, BAN is communication through or near to the body and communicating devices may be externally attached to the body, not necessarily implanted. See e.g. http://grouper.ieee.org/groups/802/802_tutorials/july06/15-06-0331-00-0ban-tutorial-on-body-area-networks.ppt specifically slide 17, which since it is from the 802.15 group is probably as official as it gets nowadays with abbreviations. The original example might be improved by mentioning capacitive coupling (which would make it stand out more from the Bluetooth crowd) but then it would be quite specific. The new explanation and example is way to restrictive. Markus Baumeister 04:51, 24 June 2007 (CDT)

start whole thing over?

The stuff here is good, but lacks overall coherent structure. There's a whole section that could become an article on network topology. There needs to be integration with OSI 7-layer model and similar articles. There needs to be history of networks that shows how DARPA kicked off the whole thing with ARPAnet, creating the IETF and the RFC process (which foreshadows open source software movement), and leading eventually to the internet and eventually the world wide web. And how about TCP/IP and routing and all that wild stuff? The collection of articles now in existence needs overall coordination. I don't know how we achieve it, given that we are all sort of stabbing at things independently. I guess we have to discuss it (in our spare time, yuk yuk). Pat Palmer 14:22, 14 May 2007 (CDT)

I think we need a fresh start. We'll probably end up saving time in the end by writing a new article rather than trying to improve this one. Where do we archive it? Greg Woodhouse 14:32, 14 May 2007 (CDT)

Umm, DARPA didn't create the RFC process, the early ARPANet community did (well, they were all DARPA contractors). J. Noel Chiappa 16:21, 15 April 2008 (CDT)

wireless vs. wired

I recommend separating wireless out completely. It is impossibly to understand wireless networks without first understand basic networking concepts such as packet switching, data link layer, etc. Then, wireless has its own issues related to radio transmission and groupings. This is a formless jumble (of good ideas) at the moment.

What to cover - Initial thoughts

Assuming that we are starting from the ground up, it makes sense to start out talking about applications that require the transfer of information between systems, such as browsing the web, sending and receiving e-mail, voice over IP (VoIP), talking to people on a wireless phone, instant messaging, online banking, etc. We can then go on to say that computer networks are the infrastructure making all of this possible. We should add that, on the physical level, networks consist of cables, phone lines, various kinds of devices (hubs, switches, etc.) and wireless transmsitters and receivers (radio, microwave, sattelite). We might go on to say that the devices comprising a physical network are often very different, and that standardized protocols describe how they should interact with eachother. It might be useful to follow a hypothetical mail message through the Internet to its destination, or something along those lines. Perhaps we can talk about the "divide and conquer" principle (how complex systems are divided into small subsystems which address smaller, simpler problems) and how "low level" protocols (or technologies) are used to move raw signals from one computer to another, either over physical media (e.g., a cable) or as a radio signal, how higher level protocols (called data link protocols) are used to reliably move digital signals (sequences of 1's and 0's from one computer to another on the same network), how still higher level protocols (like IP or IPX) are used to move data between computers that may not be connected physically or through wireless links. Then, we can go on to moving arbitrary amounts of data reliably between remote computers (layer 4, e.g., TCP), and how that data can be specially formatted and sequenced for various purposes (browsing the web, sending/receiving e-mail, talking on the phone, watching streaming video, playing a game, etc.) Of course, details about individual protocols or layers should go in separate articles, but this might provide some intuition for the reader without any technical knowledge of computer networks. Greg Woodhouse 15:18, 14 May 2007 (CDT)

clean slate

I have archived the article and will now archive the older discussions as well. Have fun! Pat Palmer 13:34, 15 May 2007 (CDT)

On the contrary, I think I'll leave this stuff here for now so we can see what our objections to the old one were. We can archive everything above here at any time though (the link is already there). Pat Palmer 13:36, 15 May 2007 (CDT)

Well, you are quick with removing ca. 2 evening of work but not so quick with replacing it with a better version. Maybe that isn't so easy. Unless someone objects I will revive the old version. Markus Baumeister 04:51, 24 June 2007 (CDT)

Are you planning on working on it? The old article had a lot of problems, but it does appear everyone sort of "gave up" on this article, and reviving interest would be a good thing. Greg Woodhouse 10:49, 24 June 2007 (CDT)

Excuse me, but I wrote it. If you have problems with it, fix them or write a better article but don't just delete the article. Or please elaborate why having no article is better than having this one. Markus Baumeister 12:13, 29 June 2007 (CDT)

I didn't delete it. I'm only asking whether you have plans to work on it or not. Greg Woodhouse 12:45, 29 June 2007 (CDT)

I would agree with Markus that simply saying an article's inadequate and "archiving" it without providing an adequate (hopefully better...) replecement isn't really helping anything. It's like doing urban renewal by tearing down the slums but not building anything new :-/ Eric M Gearhart

An urban renewal strategy that has actually been used a fair amount, alas! I'm here now, and interesting in working on the articles in the computer networking area, which I think I'm probably especially suited to do a pretty good job on. (I'm also interested in history, including the history of technology, so I can handle networking history articles too. I did a lot of work on the ARPANET and History of the Internet articles at Wikipedia before I got disgusted with the clowns there and gave up.)

So, how do people want to proceed here? If y'all are OK with me working on this, should I work with the existing text, or what? J. Noel Chiappa 12:22, 25 February 2008 (CST)

Section rewrite April 15th, 2008

I am having a go at rewriting and cleaning up this article starting with this section. Please provide feedback.

I will have a go at the other sections when I have time (hopefully not too long!).

In regards to edits where I took out some sentences, I felt they were either ambiguous, needed clarification or perhaps were better suited to separate subtopic articles rather than in this introductory article. For example:

"Since all remote access needs some kind of software running on the remote computer, the boundary between the latter usage and the two former is a bit fuzzy."

This statement is a bit vague and needs clarification for beginners, but I am not sure it is useful here anyway (it is a more advanced concept). It could probably be more appropriately handled in a subtopic (not sure which).

"Variations of this architecture ... activate fall-back servers should the master server fail."

I felt this was too technical and the language vague. More detailed aspects of multi-tier architecture could probably be handled better in that article.

I hope people find the edit useful. If not in any way, let me know, and I will take it into account for any further edits. Many thanks. Mark Jones 14:00, 15 April 2008 (CDT)

There's a lot of redundancy in this article, and some of the terminology is flat out wrong ("data" versus "information"; they are not interchangable). --Robert W King 14:47, 15 April 2008 (CDT)

I agree with that assessment. I plan to edit the other sections later when time permits and, hopefully, will remove some of the redundancy.

Regarding your addition of the word "seem", in "...seem transparent to the user..." in the context of distributed systems, it does not sound right to me. In the context of distributed systems, "transparency" has a very particular, and important, meaning as a defining characteristic of a distributed system—at least a correctly designed and implemented one. For a distributed system to only seem transparent, it implies that it might not actually be transparent and thus be a flawed system. In the distributed computing vernacular, a system's distributive nature either is, or is not, transparent but, if it is not transparent, it is not, by the definition, a "distributed system". Of course, in reality (and, most likely, in all probability), a distributed system may, in fact, only seem transparent but not actually be so, but in defining the concept we should define the ideal. (Sorry if it seems like I am picking at straws here, but it probably comes from having these concepts drilled into me by my distributed systems programming University lecturers! :-D ) Mark Jones 20:01, 15 April 2008 (CDT)

I hear you, but... one thing we learned early on in networked systems is that distributed systems have failure modes that don't occur in non-distributed systems. E.g. local procedure calls generally don't have a 'timeout' exception (and handler thereto), whereas RPC kind of has to. Of course, it all depends on the exact semantics of the particular distributed system - how much replication/etc it has. So I'd argue that a distributed system is only transparently distributed within certain constraints, e.g. 'this distributed system will continue to operate as long as we don't lose all the copies of the following N critical indexes', or something like that.

When you said if it is not transparent, it is not, by the definition, a "distributed system" I don't agree with that at all. I understand the point you're making, but you probably want a more restricted term than "distributed system", which to me is a very broad one. There are plenty of distributed systems where the fact that you're talking to a remote entity (as opposed to a local one) is perfectly visible, because people want to reflect that remote interactions have failure modes that local ones don't have. J. Noel Chiappa 21:30, 15 April 2008 (CDT)

I'd like to suggest reverting to "a distributed system is a system of remotely-connected computers that cooperate to perform tasks in a manner that is transparent to the user" and wiki-linking "transparent" somewhere that explains the topic of transparency more thoroughly; how exactly this topic is handled is up for debate as there are several types of transparency which cross-section various, semi-related, topics! Mark Jones 20:20, 15 April 2008 (CDT)

A fine definition, but... the thing you're defining is not a "distributed system", but something more restricted. I would consider the set of DNS servers to be a distributed system (after all, it's providing access to a large database, and in a distributed way), but it doesn't meet this definition, I don't think. (Most DNS client software knows it's talking to various servers.) Or how about the set of SMTP servers? I would again consider them a "distributed system", but it's definitely not transparent!

Or are we just using different definitions of "transparent"? I thought it meant 'you can't tell where your request is being handled, or whether it is being done locally or remotely', or something like that. J. Noel Chiappa 21:30, 15 April 2008 (CDT)

Popularity

A popular article in April 2010, but really needs a lot of work and, if it's meant to be a nontechnical introduction, systematic contextualization and much linking. Let's rethink the goal for this article, and then move it to approval-ready.