Search (5 results, page 1 of 1)

0.008651767 = product of:
  0.0259553 = sum of:
    0.006310384 = weight(_text_:in in 5729) [ClassicSimilarity], result of:
      0.006310384 = score(doc=5729,freq=16.0), product of:
        0.059380736 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.043654136 = queryNorm
        0.10626988 = fieldWeight in 5729, product of:
          4.0 = tf(freq=16.0), with freq of:
            16.0 = termFreq=16.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.01953125 = fieldNorm(doc=5729)
    0.019644916 = weight(_text_:und in 5729) [ClassicSimilarity], result of:
      0.019644916 = score(doc=5729,freq=22.0), product of:
        0.09675359 = queryWeight, product of:
          2.216367 = idf(docFreq=13101, maxDocs=44218)
          0.043654136 = queryNorm
        0.20304069 = fieldWeight in 5729, product of:
          4.690416 = tf(freq=22.0), with freq of:
            22.0 = termFreq=22.0
          2.216367 = idf(docFreq=13101, maxDocs=44218)
          0.01953125 = fieldNorm(doc=5729)
  0.33333334 = coord(2/6)

Abstract

In der Virtualität wird's eng. Die Möglichkeiten des Scheinbaren sind anscheinend ausgereizt. Es mangelt bald an InternetAdressen. Wenn WhirIpools und Wasclunaschinen ihren eigenen Zugang zum Internet brauchen, wird der Vorrat an Kennzahlen knapp. Um dem drohenden Mangel zu begegnen, wird seit Jahren an einer überarbeiteten Fassung des Internet-Protokolls (IP) gebastelt. Doch die Neuauflage hat bis auf ein paar Testläufe - bisher ihren Weg ins Netz noch nicht gefunden. Für Aufregung sorgte sie dennoch bereits: wegen Datenschutzproblemen. Für die Kommunikation zwischen Computern im Internet gibt es eine Art Knigge. Die protokollarische Vorschrift legt fest; wie die Rechner Daten untereinander austauschen. Doch zuvor brauchen die Maschinen Namen (wie www.fr-aktuell.de) und Anschriften (hier: 194.175.173.20), damit sie sich einander vorstellen (Shake Hands) und später Daten schicken können. Vergeben werden die Bezeichnungen von der Internet Corporation for Assigned Names and Numbers Icann). Den ersten Vorschlag für eine einheitliche Übergaberegelung machten Bob Kahn und Vint Cerf im Jahr 1974. Damals versuchten im inzwischen legendären, militärisch genutzten Arpanet kaum tausend Großrechner an etwa 250 Standorten miteinander zu kommunizieren. Um Ordnung in das Sprachengewirr der verschiedenen Bautypen zu bringen, mussten Regeln her. Die Idee entwickelte sich zum Protokoll, das nach Informatik-Manier mit dem Kürzel TCP/IP belegt wurde. Mit etwa 100000 angeschlossenen Computern wurde das Netz 1983 zivil - und TCP/IP zum offiziellen Standard. Derzeit regelt die vierte Version des Internet-Protokolls (IPv4) den Bit-Transport. Die Adresse wird jedem Datenpaket vorangestellt. Sie besteht aus Ziffern und ist exakt 32 Bit lang. Daraus ergeben sich mehr als 4,2 Milliarden Zahlenkombinationen. Genug für einen Globus, auf dem erst kürzlich der sechsmilliardste Erdenbürger das Licht der realen Welt erblickte - dachten die Computer-Operateure damals. Dann kam das World Wide Web.
Der Geniestreich aus dem Europäischen Labor für Teilchenphysik (Cern) in Genf machte aus dem Wissenschaftsnetz ein Massenmedium. Zudem erfuhr die elektronische Post einen Aufschwung. Das Wachstum der Netze sprengt alle Erwartungen", resümiert Klaus Birkenbihl vom InformatikForschungszentrum GMI). Jede Web-Site, jede E-Mail-Box, jeder Computer, der per Standleitung online ist, braucht eine eindeutige Identifizierung. Die Schätzungen, wie viele IPv4-Adressen noch frei sind, schwanken zwischen 40 und zehn Prozent. Der Verbrauch jedenfalls steigt rasant: Die Anzahl der WebSites steuert derzeit auf eine Milliarde zu, weit mehr Netznummern gehen bereits für E-Mail-Anschriften drauf. Den Adressraum weiter ausschöpfen werden demnächst die intelligenten Haushaltsgeräte. Der Laden an der Ecke will wissen, welcher Kühlschrank die Milch bestellt hat, die Videozentrale braucht für das Überspielen des Films die Kennung des PC-Recorders, der Computer des Installateurs benötigt die IP-Anschrift der Heizungsanlage für die Fernwartung. Handys, die später Nachrichten übers Internet schicken, und Internet-Telefonie gehen möglicherweise leer aus. Doch bevor Internet-Adressen zur heiß begehrten Schieberware werden, soll ein neues Adresssystern mit mehr Möglichkeiten her. Schon 1990 hatte sich die Internet Engineering Task Force (IETF) Gedanken über einen neues Internet-Protokoll mit einem größeren Adressangebot gemacht. Im IETF kümmern sich Forscher, Soft- und HardwareIngenieure um die fortlaufende Verbesserung von Architektur und Arbeit des Netz werks. Eine ihrer Arbeitsgruppen prognostizierte, der IPv4-Vorrat gehe 2005 zu Ende. Fünf Jahre dauerte es, dann waren sich alle Internet-Gremien einig: Eine neue Protokollversion, IPv6, muss her. Dann passierte weiter nichts. Endlich verkündete 1999 Josh Elliot von der Icann, ab sofort würden neue Anschriften verteilt. Ein historischer Moment", freute er sich.
Der neue 128-Bit-Header treibt die Möglichkeiten ins Astronomische: 3,4 mal zehn hoch 38 Adressen, eine 3,4 mit 38 Nullen. -Das IPv6-Forum zerhackte den Zahlentrumm in anschauliche Stücke: Pro Quadratmillimeter Erdoberfläche stehen nun zirka 667 Billiarden, pro Mensch 6,5 mal zehn hoch 28 Adressen, bereit." Eine Billiarde bringt es immerhin auf respektable 15 Nullen. Schon kurz darauf ging ein Aufschrei durch die Netzgemeinde. Das neue Protokoll schrieb die weltweit eindeutigen Seriennummern bestimmter Netzwerkkarten auf den virtuellen Adressaufkleber. Die Ethernet-Adapter bewerkstelligen den Datentransport bei Computern, die über eine Standleitung, ein Koaxialkabel, dauernd online sind. Die Spur von Ethernet-Usern wäre damit leicht zu verfolgen gewesen, ihre Nutzerprofile, ihre Surfgewohnheiten einsehbar wie offene Bücher. Das Problem, ließ Icann nun wissen, sei behoben: Es gebe keine festen Kennzahlen mehr in den Adressköpfen. Bei jedem Hochfahren eines Rechners oder sogar noch öfter werden die Nummern neu durchgemischt", erläutert Hans Petter Dittler, stellvertretender Vorsitzender der deutschen Sektion der Internet Society. Das Betriebssystem Linux kann bereits mit dem IPv6 arbeiten. Microsoft will den Standard in das nächste Windows-Betriebssystem einbauen: "Wir denken, der vorgeschlagene Standard ist wichtig zum Schutz der Privatsphäre der Internet-Nutzer", sagt Jawad Khaki, Vizepräsident für Netzwerke. Seit einigen Tagen steht auf der Microsoft-Homepage eine Vorab-Version von lPv6 für Windows 2000 zum Herunterladen bereit. Geradezu euphorisch gibt sich Protokoll-Chef Vint Cerf. Mit IPv6 haben wir die Grundlage dafür", philosophierte der Internet-Daddy auf dem ersten lPv6-Kongress 1999 in Berlin, "das Internet von unserem Planeten über den Mars und die Asteroiden bis in den Weltraum hinaus auszudehnen." Doch im Internet-Alltag wird das alte Protokoll noch lange Vorrang haben. Grund sind handfeste Programmier-Probleme. Denn Software, die sich explizit auf die vierte IP-Version bezieht, muss umgeschrieben werden - etwa um mit den längeren Adressfeldern umgehen zu können. Hubert Martens vom Münchner Multinet Services befürchtet gar einen InternetCrash: "Das Jahr-2000-Problem war harmlos gegen das, was uns mit lPv6 droht."

0.003159021 = product of:
  0.018954126 = sum of:
    0.018954126 = weight(_text_:und in 3321) [ClassicSimilarity], result of:
      0.018954126 = score(doc=3321,freq=2.0), product of:
        0.09675359 = queryWeight, product of:
          2.216367 = idf(docFreq=13101, maxDocs=44218)
          0.043654136 = queryNorm
        0.19590102 = fieldWeight in 3321, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          2.216367 = idf(docFreq=13101, maxDocs=44218)
          0.0625 = fieldNorm(doc=3321)
  0.16666667 = coord(1/6)

Abstract

Lange Zeit war es nur eine schöne Vision: Wo auch immer man im Haus den Computer an eine Steckdose stöpselt - das Internet ist schon da, ohne Kabelgewirr oder stör-empfindliche Funkstrecken. Was einfach klingt, ist technisch kompliziert - und kann als Nebenwirkung Störungen bringen, die Funkamateure empören

0.0016629322 = product of:
  0.009977593 = sum of:
    0.009977593 = weight(_text_:in in 4898) [ClassicSimilarity], result of:
      0.009977593 = score(doc=4898,freq=10.0), product of:
        0.059380736 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.043654136 = queryNorm
        0.16802745 = fieldWeight in 4898, product of:
          3.1622777 = tf(freq=10.0), with freq of:
            10.0 = termFreq=10.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0390625 = fieldNorm(doc=4898)
  0.16666667 = coord(1/6)

Abstract

This article will examine the Z39.50 Information Retrieval protocol. It will look at some of the history of the protocol, its operation, and some of the major projects that have made use of it. There has been enough written (perhaps too much) about Z39.50 in the last several years so it is not intended to be a tutorial or detailed description of the protocol. The material that will be presented will try and put some context around the discussion. For those readers who are interested in delving into Z39.50 in a more technical manner, references to much of the material that has been written about it over the years will be provided at the end. Finally, the article will conclude with some thoughts on how technology and technological infrastructure have changed in the years since Z39.50 was initially developed and deployed, and where the protocol has so far lived up to its goals, and where it has perhaps failed to meet some of the high expectations that at least some people involved in the Z39.50 community held for it. The article will conclude with some of the author's speculations (and they are really no more than that) of what the future role of Z39.50 is likely to be.

0.0014873719 = product of:
  0.008924231 = sum of:
    0.008924231 = weight(_text_:in in 5155) [ClassicSimilarity], result of:
      0.008924231 = score(doc=5155,freq=8.0), product of:
        0.059380736 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.043654136 = queryNorm
        0.15028831 = fieldWeight in 5155, product of:
          2.828427 = tf(freq=8.0), with freq of:
            8.0 = termFreq=8.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0390625 = fieldNorm(doc=5155)
  0.16666667 = coord(1/6)

Abstract

Hinich and Molyneux review the literature of internet measurement and note three results consistently to be found in network traffic studies. These are "self-similarity," "long-range dependence," by which is meant that events in one time are correlated with events in a previous time and remain so through longer time periods than expected, and "heavy tails" by which they mean many small connections with low byte counts and a few long connections with large byte counts. The literature also suggests that conventional time series analysis is not helpful for network analysis. Using a single day's traffic at the Berkeley National Labs web server, cumulated TCP flows were collected, log transforms were used with the adding of .01 to all values allowing log transforms of the zero values, and providing a distribution that overcomes the heavy tail problem. However, Hinich's bicorrelation test for nonlinearity using overlapping moving windows found strong evidence of nonlinear structures. Time series analysis assumes linear systems theory and thus additivity and scalability. Spectral analysis should provide large peaks at the lowest frequencies if long range dependence is present since the power spectrum would go to infinity if the frequency goes to zero. This does not occur and so long range dependence must be questioned, at least until it is determined what effect other OSI layers may have on the TCP data.

0.0010517307 = product of:
  0.006310384 = sum of:
    0.006310384 = weight(_text_:in in 3813) [ClassicSimilarity], result of:
      0.006310384 = score(doc=3813,freq=4.0), product of:
        0.059380736 = queryWeight, product of:
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.043654136 = queryNorm
        0.10626988 = fieldWeight in 3813, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          1.3602545 = idf(docFreq=30841, maxDocs=44218)
          0.0390625 = fieldNorm(doc=3813)
  0.16666667 = coord(1/6)

Abstract

Information retrieval (IR) protocols support effective and interoperable intersystem search and retrieval. Although intersystem search methods have been envisioned and under development since the 1970s, it was the Z39.50 IR protocol, first released in 1988, that demonstrated real-world possibilities for such search and retrieval. As the networked information environment changed with the emergence of the World Wide Web, the need for standard IR protocols did not disappear, and one can argue the need is even more compelling given both the visible and invisible Web. A new protocol, based on the experience from Z39.50 but simpler and more comprehensible than Z39.50, is now being used for Web search and retrieval. Search and retrieve via URL (SRU) uses Web technologies and standards resulting in a Web friendly protocol that provides standard search access to existing Z39.50 resources and a wide-range of new non-catalog digital resources. This entry provides both an overview of the two protocols and technical details to understand both. A brief discussion of IR and communications protocols provides background to the specifics of these two IR protocols. Although communication protocols are by their nature technical specifications, this entry focuses on an overview of the functions and capabilities of the protocols. It uses technical concepts and terminology from the protocols to help explain how the protocols work but limits discussion of technical details.