Architecture Technology - World Largest Resort

Biocybernetics

Biocybernetics is the application of cybernetics to the biological science, comprised of biological disciplines that benefit from the application of cybernetics: neurology, multicellular systems and others. Biocybernetics plays a major role in systems biology, seeking to integrate different levels of information to understand how biological systems function.

RESEARCH IN THE BIOCYBERNETICS LABORATORY these days is somewhat eclectic, but - as alway interdisciplinary. Our work typically involves integration of theory with real laboratory data, using biomodeling, computational and biosystems approaches. Our current problem domains are physiological systems, disease processes, pharmacology, and some post-genomic bioinformatics. The pedagogy of the lab involves development and exploitation of the synergistic and methodologic interface between structural and computational biomodeling with laboratory data, or computational systems biology, with a focus on integrated approaches for solving complex biosystem problems from sparse biodata (e.g. in physiology, medicine and pharmacology), as well as voluminous biodata (e.g. from genomic libraries and DNA array data).

NEUROENDOCRINE PHYSIOLOGY RESEARCH
Our primary neuroendocrine research project involves experimental studies of thyroid hormone regulation and metabolism.Our overall long-term goal is enhancement of understanding of the hierarchical mechanisms of control of thyroid hormone (TH) production, organ distribution metabolism and excretion in mammals and fishes. Our approach is quantitative and integrative, with emphasis on both whole-organism and local organ TH regulation in health and disease states (integrated regulation of sources and sinks). Over the last 30 years, our contributions to the literature of TH metabolism and physiology have been realized using an integrated multidisciplinary investigative approach. Physiology and biochemistry laboratory methodologies have been supplemented with two distinct and highly sophisticated biomodeling and experiment design approaches pioneered in our laboratory. Both treat in vivo derived multiorgan-whole-body data, one collected from steady state tracer kinetic experiments using multisite hormone constant infusion inputs, the other from multisite hormone pulse-dose transient response kinetic experiments. We are also currently embarking on a new modality, using a new technology, MicroPET, for whole-body dynamic functional imaging, for enhancing our in vivo TH kinetic analysis approach.

We continue to emphasize three focus areas, in health versus disease states: (1) the arterio-enterohepatic system, particularly the role of intestinal components and processes in overall TH regulation (2) whole-body production of the hormone triiodothyronine (T3) from thyroxine (T4) in nonendocrine organs and from the thyroid; and (3) local organ T3 production rates, which have not been fully quantified in any organ, in any species, a problem we have nearly resolved in our most recent work.

We are also exploring alternative mechanisms including a possible "chaos" explanation for the well-established pulsatile nature of secretion of hormones from the pituitary gland. These studies utilize techniques of computational biology and nonlinear biomodeling, some developed by us, and others by collaborators at MIT, applied to human pituitary data supplied by collaborators at the University of Oregon.

SIP Session Initiation Protocol - I

The next evolutionary step after VoIP, networks, and IP Telephony, “SIP will bring Internet telephony to users’ desktops.” SIP represents the capability to reach someone regardless of location or device. Just as email can find you once you are logged in, SIP can do the same. SIP signals multiple devices until it finds you, or respects the fact that you do not want to be found. SIP is a signaling protocol. Its job is to broker communications between two devices, and once that communication is set up, SIP backs out. SIP has many of the characteristics of HTTP. It looks and acts like a URL. SIP addresses may look like an email address or even a telephone number. In fact, your email address is one way for SIP to find you. Some Example

sip:friends@latest-tech-fc.com
sip:+8185551234@gateway.com
tel:+8185551234

SIP resides at the application layer of the network and establishes, modifies, and terminates multimedia sessions between intelligent devices. This is an important concept in the world of convergence. Data networks have traditionally been unintelligent, but with very smart endpoints and devices. Telephone networks are inherently very smart, but with unintelligent endpoints (telephones).
SIP extends the intelligence of a data network out to the end user at the edge, while allowing the lesser intelligent core to forward communications requests without much effort. This makes the data network run more efficiently and effectively by putting intelligence where it is needed most. SIP also works between data and traditional telephony networks. It can broker a call between a manager’s analog home phone and an employee’s SIP enabled soft phone. If the employee is on a telephone call, it alerts the manager to another way of contacting the employee, such as sending an instant message using voice, perhaps via VxML, which is then converted to a simple text message and sent as an instant message to the employee’s PC. All the manager has to remember is the employee’s phone number.
SIP uses straightforward messages to set up, modify and terminate calls:

Invite – just like it sounds
Ack – call acceptance
Cancel – terminate search
Register – location of user (very important to the concept of presence)
Bye – ends session

SIP also easily integrates with other protocols such as the Simple Mail Transport Protocol (SMTP) as well as working with Domain Name Servers (DNS) and the Lightweight Directory Access Protocol (LDAP). SIP can handle connectionless requests using the User Datagram Protocol (UDP), which is used for voice, or connection oriented requests using the Transmission Control Protocol (TCP), which would manage a chat session. All these protocols form a communications fabric that makes it easier to locate someone, regardless of how they spell their name or what telephone number they are using. According to Frances Carincross, an industry visionary, the corporate communications network, along with the Internet, will be the “connective tissue” of an enterprise. This corporate connective tissue enables workers that are at home, in the office, or on the road to stay in touch with each other as well as customers and suppliers.

SIP Session Initiation Protocol – II

How Does it Work?
SIP provides connectivity and access. It enables communications between two SIP devices on a peer-topeer basis, and acts as a client server by allowing SIP end users, called user agents (UA) to act as clients when initiating a request, or as servers when responding to a request. This could mean an attempt to call a SIP device results in a redirection to another device. The SIP infrastructure can have SIP servers to act as proxies, gateways, registrars and redirectors to bridge into multiple devices or other environments such as linking to the public switched telephone network (PSTN) or a corporate PBX. On a peer-to-peer basis, SIP makes an invitation, which is either acknowledged or cancelled. Once the set up is complete, the Real Time Protocol (RTP) takes over to provide the actual communications. When the call is completed, the user hangs up and the SIP “Bye” message is sent out to end the session. A diagram of a simple SIP peer-to-peer call follows.

Session Initiation Protocol – SIP



Calling into a non-SIP environment requires registering to be accessible on more than one device, or for changed locations. In this case, a SIP proxy server provides services such as redirecting a call to where you have moved, launching parallel requests (forking) to more than one device or connecting into a non-SIP device such as an analog or digital PBX telephone (SIP gateway). SIP proxy servers also track users by dynamically updating changes and noting when the user is on line. This is the concept of “presence” and it enables a user to be found regardless of physical location. The primary function of SIP is to set up a connection. How communications take place depends on the device being used, the user’s status, and location in the network (presence) and the preferences listed when the user registered. For example, the manager might be on a conference call at his/her desk. If the second line rings and the manager puts the conference call on hold to speak with a client, the other participants have to tolerate music on hold until the conference operator can mute the manager’s port. Instead of disrupting a conference call the manger’s profile would state that if a call comes in from this particular client, identified by using caller ID, the caller has the option of engaging the manager in a chat session. An instant message on the manager’s PC screen might appear saying a client is trying to reach the manager (an “invite”) and he/she could accept (an ACK). The client could receive a message that says the manager is available to chat and see on his/her PC that a chat session has been set up. All of this depends on the manager’s network, devices, and desktop capabilities.
“There is already rapid growth in the number of novel and useful functions in new SIP-based systems,” said Jay Batson, founder and Chairman of Pingtel Corp., a pioneer and leader in SIP phones and technology. “Emerging SIP products are highly flexible and customizable, and are also rigorously tested for multi-vendor interoperability. This combination enables customers to find and deploy products that enhance their businesses much more simply and easily than with traditional voice systems.” SIP is an evolving standard that is slowly gaining in acceptance and use in the telecommunications industry. The number of popular PBX features it supports is also growing. The cost of SIP phones, although currently higher than digital or IP phones, will decrease as demand increases and soft phones offer more cost-effective ways to realize the benefits of SIP in locations where their use is practical (e.g., call centers). Only recently have SIP telephones begun to reach price points similar to today’s digital PBX phones.

Security, as with any IP-based device or service, is an issue, although there are security measures that can be taken such as embedding a firewall and NAT within the SIP proxy (Windows XP does this) or using stand-alone gateways. Telecommunications service providers must still address the issue of mapping PSTN numbers and SIP addresses. Recently, the Department of Commerce said it would support the electronic numbering system, known as ENUM to allow consumers to specify a single identification system for their telephone numbers, e-mail, fax numbers, cell phone numbers and instant messaging addresses. The ENUM standard, known as E.164.arpa translates telephone numbers to Internet addresses and vice versa. Enhanced 911 services are also a challenge with not just SIP, but all IP telephony devices due to the inherent mobility of IP. Since these devices essentially float in the network, ensuring E911 location information becomes a challenge. Within the SIP community several proposals have been offered ranging from installing GPS chip sets in the devices to having users simply log on to specify their location. Because a growing number of states require location information for E911 calls, this issue calls for some type of standardization across the SIP product line.

MGCP - Media Gateway Control Protocol - I

The Media Gateway Control Protocol (MGCP) implements the media gateway control
interface as a set of transactions. The transactions are composed of a command
and a mandatory response. There are nine commands:

* EndpointConfiguration

* CreateConnection

* ModifyConnection

* DeleteConnection

* NotificationRequest

* Notify

* AuditEndpoint

* AuditConnection
* RestartInProgress

The first five commands are sent by the Call Agent to a gateway. The
Notify command is sent by the gateway to the Call Agent.
The Call Agent may send either of the Audit commands to the gateway, and
the gateway may send a RestartInProgress command to the Call Agent.

General Description

All commands are composed of a Command header, optionally followed by
a session description.

All responses are composed of a Response header, optionally followed
by session description information.

Headers and session descriptions are encoded as a set of text lines,
separated by a carriage return and line feed character (or,
optionally, a single line-feed character). The session descriptions
are preceded by an empty line.

MGCP uses a transaction identifier to correlate commands and
responses. The transaction identifier is encoded as a component of
the command header and repeated as a component of the response header
Commands and responses SHALL be encoded in accordance with the
grammar, which, per RFC 2234, is case-insensitive except for the SDP
part. Similarly, implementations SHALL be capable of decoding
commands and responses that follow the grammar. Additionally, it is
RECOMMENDED that implementations tolerate additional linear white
space.

Some productions allow for use of quoted strings, which can be
necessary to avoid syntax problems. Where the quoted string form is
used, the contents will be UTF-8 encoded [20], and the actual value
provided is the unquoted string (UTF-8 encoded). Where both a quoted
and unquoted string form is allowed, either form can be used provided
it does not otherwise violate the grammar.

In the following, we provide additional detail on the format of MGCP
commands and responses.



Command Header

The command header is composed of:

* A command line, identifying the requested action or verb, the
transaction identifier, the endpoint towards which the action is
requested, and the MGCP protocol version,

* A set of zero or more parameter lines, composed of a parameter
name followed by a parameter value.

Unless otherwise noted or dictated by other referenced standards
(e.g., SDP), each component in the command header is case
insensitive. This goes for verbs as well as parameters and values,
and hence all comparisons MUST treat upper and lower case as well as
combinations of these as being equal.

Command Line

The command line is composed of:

* The name of the requested verb,

* The identification of the transaction,

* The name of the endpoint(s) that are to execute the command (in
notifications or restarts, the name of the endpoint(s) that is
issuing the command),

* The protocol version.

These four items are encoded as strings of printable ASCII
characters, separated by white spaces, i.e., the ASCII space (0x20)
or tabulation (0x09) characters. It is RECOMMENDED to use exactly
one ASCII space separator. However, MGCP entities MUST be able to
parse messages with additional white space characters.

MGCP - Media Gateway Control Protocol -II

Coding of the Requested Verb

The verbs that can be requested are encoded as four letter upper or
lower case ASCII codes (comparisons SHALL be case insensitive) as
defined in the following table:

-----------------------------
| Verb | Code |
|----------------------|------|
| EndpointConfiguration| EPCF |
| CreateConnection | CRCX |
| ModifyConnection | MDCX |
| DeleteConnection | DLCX |
| NotificationRequest | RQNT |
| Notify | NTFY |
| AuditEndpoint | AUEP |
| AuditConnection | AUCX |
| RestartInProgress | RSIP |
-----------------------------

The transaction identifier is encoded as a string of up to 9 decimal
digits. In the command line, it immediately follows the coding of
the verb.

New verbs may be defined in further versions of the protocol. It may
be necessary, for experimentation purposes, to use new verbs before
they are sanctioned in a published version of this protocol.
Experimental verbs MUST be identified by a four letter code starting
with the letter X, such as for example XPER.

Transaction Identifiers

MGCP uses a transaction identifier to correlate commands and
responses. A gateway supports two separate transaction identifier
name spaces:

* a transaction identifier name space for sending transactions, and

* a transaction identifier name space for receiving transactions.

At a minimum, transaction identifiers for commands sent to a given
gateway MUST be unique for the maximum lifetime of the transactions
within the collection of Call Agents that control that gateway.
Thus, regardless of the sending Call Agent, gateways can always
detect duplicate transactions by simply examining the transaction
identifier. The coordination of these transaction identifiers
between Call Agents is outside the scope of this specification
though.

Transaction identifiers for all commands sent from a given gateway
MUST be unique for the maximum lifetime of the transactions
regardless of which Call Agent the command is sent to. Thus, a Call
Agent can always detect a duplicate transaction from a gateway by the
combination of the domain-name of the endpoint and the transaction
identifier.

The transaction identifier is encoded as a string of up to nine
decimal digits. In the command lines, it immediately follows the
coding of the verb.

Transaction identifiers have values between 1 and 999,999,999 (both
included). Transaction identifiers SHOULD NOT use any leading
zeroes, although equality is based on numerical value, i.e., leading
zeroes are ignored. An MGCP entity MUST NOT reuse a transaction
identifier more quickly than three minutes after completion of the
previous command in which the identifier was used.

Coding of the Protocol Version

The protocol version is coded as the keyword MGCP followed by a white
space and the version number, and optionally followed by a profile
name. The version number is composed of a major version, coded by a
decimal number, a dot, and a minor version number, coded as a decimal
number. The version described in this document is version 1.0.

The profile name, if present, is represented by white-space separated
strings of visible (printable) characters extending to the end of the
line. Profile names may be defined for user communities who want to
apply restrictions or other profiling to MGCP.

In the initial messages, the version will be coded as:

MGCP 1.0

An entity that receives a command with a protocol version it does not
support, MUST respond with an error (error code 528 - incompatible
protocol version, is RECOMMENDED). Note that this applies to
unsupported profiles as well.

MGCP - Media Gateway Control Protocol -III

Capabilities

Capabilities inform the Call Agent about endpoints' capabilities when
audited. The encoding of capabilities is based on the Local
Connection Options encoding for the parameters that are common to
both, although a different parameter line code is used ("A"). In
addition, capabilities can also contain a list of supported packages,
and a list of supported modes.

The parameters used are:

A list of supported codecs.
The following parameters will apply to all codecs specified in
this list. If there is a need to specify that some parameters,
such as e.g., silence suppression, are only compatible with some
codecs, then the gateway will return several Capability
parameters; one for each set of codecs.

Packetization Period:
A range may be specified.

Bandwidth:
A range corresponding to the range for packetization periods may
be specified (assuming no silence suppression). If absent, the
values will be deduced from the codec type.

Echo Cancellation:
"on" if echo cancellation is supported, "off" otherwise. The
default is support.

Silence Suppression:
"on" if silence suppression is supported for this codec, "off"
otherwise. The default is support.

Gain Control:
"0" if gain control is not supported, all other values indicate
support for gain control. The default is support.

Type of Service:
The value "0" indicates no support for type of service, all other
values indicate support for type of service. The default is
support.

Resource Reservation Service:
The parameter indicates the reservation services that are
supported, in addition to best effort. The value "g" is encoded
when the gateway supports both the guaranteed and the controlled
load service, "cl" when only the controlled load service is
supported. The default is "best effort".

Encryption Key:
Encoding any value indicates support for encryption. Default is
no support which is implied by omitting the parameter.

Type of network:
The keyword "nt", followed by a colon and a semicolon separated
list of supported network types. This parameter is optional.

Packages:
The packages supported by the endpoint encoded as the keyword "v",
followed by a colon and a character string. If a list of values
is specified, these values will be separated by a semicolon. The
first value specified will be the default package for the
endpoint.

Modes:
The modes supported by this endpoint encoded as the keyword "m",
followed by a colon and a semicolon-separated list of supported
connection modes for this endpoint.

Lack of support for a capability can also be indicated by excluding
the parameter from the capability set.

An example capability is:

A: a:PCMU;G728, p:10-100, e:on, s:off, t:1, v:L,
m:sendonly;recvonly;sendrecv;inactive

The carriage return above is included for formatting reasons only and
is not permissible in a real implementation.

If multiple capabilities are to be returned, each will be returned as
a separate capability line.

Since Local Connection Options can be extended, the list of
capability parameters can also be extended. Individual extensions
may define how they are reported as capabilities. If no such
definition is provided, the following defaults apply:

* Package Extension attributes: The individual attributes are not
reported. Instead, the name of the package is simply reported in
the list of supported packages.

* Vendor Extension attributes: The name of the attribute is reported
without any value.

* Other Extension attributes: The name of the attribute is reported
without any value.


Coding of Event Names

Event names are composed of an optional package name, separated by a
slash (/) from the name of the actual event. The
wildcard character star ("*") can be use to refer to all packages.
The event name can optionally be followed by an at sign (@) and the
identifier of a connection (possibly using a wildcard) on which the
event should be observed. Event names are used in the
RequestedEvents, SignalRequests, ObservedEvents, DetectEvents, and
EventStates parameters.

Events and signals may be qualified by parameters defined for the
event/signal. Such parameters may be enclosed in double-quotes (in
fact, some parameters MUST be enclosed in double-quotes due to
syntactic restrictions) in which case they are UTF-8 encoded [20].

The parameter name "!" (exclamation point) is reserved for future use
for both events and signals.

Each signal has one of the following signal-types associated with it:
On/Off (OO), Time-out (TO), or Brief (BR). (These signal types are
specified in the package definitions, and are not present in the
messages.) On/Off signals can be parameterized with a "+" to turn the
signal on, or a "-" to turn the signal off. If an on/off signal is
not parameterized, the signal is turned on. Both of the following
will turn the vmwi signal (from the line package "L") on:

L/vmwi(+)
L/vmwi

In addition to "!", "+" and "-", the signal parameter "to" is
reserved as well. It can be used with Time-Out signals to override
the default time-out value for the current request. A decimal value
in milliseconds will be supplied. The individual signal and/or
package definition SHOULD indicate if this parameter is supported for
one or more TO signals in the package. If not indicated, TO signals
in package version zero are assumed to not support it, whereas TO
signals in package versions one or higher are assumed to support it.
By default, a supplied time-out value MAY be rounded to the nearest
non-zero value divisible by 1000, i.e., whole second. The individual
signal and/or package definition may define other rounding rules. All
new package and TO signal definitions are strongly encouraged to
support the "to" signal parameter.

The following example illustrates how the "to" parameter can be used
to apply a signal for 6 seconds:

L/rg(to=6000)
L/rg(to(6000))

The following are examples of event names:

-----------------------------------------------------------
| L/hu | on-hook transition, in the line package |
| F/0 | digit 0 in the MF package |
| hf | Hook-flash, assuming that the line package|
| | is the default package for the endpoint. |
| G/rt@0A3F58 | Ring back signal on connection "0A3F58" |
-----------------------------------------------------------

In addition, the range and wildcard notation of events can be used,
instead of individual names, in the RequestedEvents and DetectEvents
parameters. The event code "all" is reserved and refers to all
events or signals in a package. The star sign ("*") can be used to
denote "all connections", and the dollar sign ("$") can be used to
denote the "current" connection.

The following are examples of such notations:

---------------------------------------------------------
| M/[0-9] | Digits 0 to 9 in the MF package. |
| hf | Hook-flash, assuming that the line package|
| | is a default package for the endpoint. |
| [0-9*#A-D]| All digits and letters in the DTMF |
| | packages (default for endpoint). |
| T/all | All events in the trunk package. |
| R/qa@* | The quality alert event on all |
| | connections. |
| G/rt@$ | Ringback on current connection. |
---------------------------------------------------------

MGCP - Media Gateway Control Protocol - IV

ConnectionMode

The connection mode describes the mode of operation of the
connection. The possible values are:

--------------------------------------------------------
| Mode | Meaning |
|-------------|------------------------------------------|
| M: sendonly | The gateway should only send packets |
| M: recvonly | The gateway should only receive packets |
| M: sendrecv | The gateway should send |
| | and receive packets |
| M: confrnce | The gateway should place |
| | the connection in conference mode |
| M: inactive | The gateway should neither |
| | send nor receive packets |
| M: loopback | The gateway should place |
| | the circuit in loopback mode. |
| M: conttest | The gateway should place |
| | the circuit in test mode. |
| M: netwloop | The gateway should place |
| | the connection in network loopback mode.|
| M: netwtest | The gateway should place the connection |
| | in network continuity test mode. |
--------------------------------------------------------
Note that irrespective of the connection mode, signals applied to the
connection will still result in packets being sent

ConnectionParameters

Connection parameters are encoded as a string of type and value
pairs, where the type is either a two-letter identifier of the
parameter or an extension type, and the value a decimal integer.
Types are separated from value by an '=' sign. Parameters are
separated from each other by a comma. Connection parameter values
can contain up to nine digits. If the maximum value is reached, the
counter is no longer updated, i.e., it doesn't wrap or overflow.

The connection parameter types are specified in the following table:

-----------------------------------------------------------------
| Connection parameter| Code | Connection parameter |
| name | | value |
|---------------------|------|------------------------------------|
| Packets sent | PS | The number of packets that |
| | | were sent on the connection. |
| Octets sent | OS | The number of octets that |
| | | were sent on the connection. |
| Packets received | PR | The number of packets that |
| | | were received on the connection. |
| Octets received | OR | The number of octets that |
| | | were received on the connection. |
| Packets lost | PL | The number of packets that |
| | | were lost on the connection |
| | | as deduced from gaps in the |
| | | RTP sequence number. |
| Jitter | JI | The average inter-packet arrival |
| | | jitter, in milliseconds, |
| | | expressed as an integer number. |
| Latency | LA | Average latency, in milliseconds, |
| | | expressed as an integer number. |
-----------------------------------------------------------------

The set of connection parameters can be extended in two different
ways:

* Package Extension Parameters (preferred)

* Vendor Extension Parameters



Package Extension Connection Parameters are defined in packages which
provides the following benefits:

* A registration mechanism (IANA) for the package name.

* A separate name space for the parameters.

* A convenient grouping of the extensions.

* A simple way to determine support for them through auditing.

The package extension mechanism is the preferred extension method.

Vendor extension parameters names are composed of the string "X-"
followed by a two or more letters extension parameter name.

Call agents that receive unrecognized package or vendor connection
parameter extensions SHALL silently ignore these parameters.

An example of connection parameter encoding is:

P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48

XMPP - Extensible Messaging and Presence Protocol

XMPP (Extensible Messaging and Presence Protocol) is a protocol based on Extensible Markup Language (XML) and intended for instant messaging (IM) and online presence detection. It functions between or among servers, and facilitates near-real-time operation. The protocol may eventually allow Internet users to send instant messages to anyone else on the Internet, regardless of differences in operating systems and browsers.
XMPP is sometimes called the Jabber protocol, but this is a technical misnomer. Jabber, an IM application similar to ICQ (I Seek You) and others, is based on XMPP, but there are many applications besides Jabber that are supported by XMPP. The IEEE XMPP working group, a consortium of engineers and programmers, is adapting XMPP for use as an Internet Engineering Task Force (IETF) technology. In addition, the Messaging and Presence Interoperability Consortium (MPIC) is considering XMPP as an important interoperability technology. Eventually, XMPP is expected to support IM applications with authentication, access control, a high measure of privacy, hop-by-hop encryption, end-to-end encryption, and compatibility with other protocols.
IBM and Microsoft are working on a similar standard called SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) based on Session Initiation Protocol (SIP).

XMPP Standards Foundation
The XMPP Standards Foundation (formerly the Jabber Software Foundation) is an independent, nonprofit organization whose primary mission is to define open protocols for presence, instant messaging, and real-time communication and collaboration on top of the IETF's Extensible Messaging and Presence Protocol (XMPP). The XSF also provides information and infrastructure to the worldwide community of Jabber/XMPP developers, service providers, and end users. Although our elected members and self-selected sponsors provide a legal and financial basis for the organization, the XSF not a closed industry consortium but instead is a completely open and transparent standards development organization in which any interested individual may freely participate. Furthermore, our developer-friendly standards process avoids design by committee and places a premium on the values that built the Internet in the first place: rough consensus and running code

Wi-Fi Technology - I

Wi-Fi
Wi-Fi is a technology that allows data transfer over specified radio frequencies; this in turn removes the need for cabled connections making device portability possible. The Wi-Fi revolution has been trumpeted on a number of occasions but has stalled each time on security fears or cost, but as mobile hones have driven the publics understanding of wireless communication the consumer appetite for Wi-Fi products has grown steadily to a point where it became commercially viable.

How does it work?
Moving data using radio frequency is nothing new, in fact the first Morse code radio transmission has a lot in common with today's wifi technology, after sending what is in effect the first binary wireless transmission mankind spent the next 20 years perfecting the reproduction of the human voice in an analogue format.
The telephone while revolutionary did mask the ability of data transmission, this was not left to rot as militaries around the world continued to develop the sending of data via RF transmissions. WIFI of today is a distant cousin of that Morse signal, although instead of a low bandwidth dot and dashes being sent thousands of bits of data are sent every second and we are now measuring in kilobits per second and with newer technologies even megabits.
Wifi as a standard uses the 2.4 GHz range which is largely unused by the European military and other RF users like mobile communications, this frequency band is then broken down into channels which a wireless device can use to transmit data and in order to avoid interference the devices can frequency hop or jump between them mid data stream.
So we have a method of moving data over RF but each device needs to be connected and enabled to work with Wi-Fi, this is in effect like giving each device in your network a handheld radio (except they work at much high frequencies). Over this radio link the binary DataStream carries your data for example a webpage back to the device that requested it. A laptop for example would have a wireless access card or dongle this is both a transmit and receive device, this could connect to another laptop with the same setup and create a point to point connection. It is far more likely that the laptop and any other client device will connect to a router or access point to join a much larger wireless network.
Performance of any wireless link is limited by the same factors that affect your radio or TV signal, weather, distance, power and walls or objects, again an example if you use an indoor aerial for your TV your signal is weaker and therefore the picture quality drops. With a wifi network if the signal strength or quality drops the effective data rate is reduced as more packets are re sent to counteract the errors, so it is important to bear in mind the maximum achievable range of a Wi-Fi enabled device may be at the minimum sustainable speed.

Wi-Fi Variants
The accepted Wi-Fi standards are set by the Institute of Electrical and Electronics Engineers or IEEE, 802.11b was the first to market and is the slowest in terms of raw bandwidth but is also the cheapest to produce equipment for, with speeds up to 11mbits this is the format that is most prevalent in today's electronics marketplace.
Then there is 802.11a which strangely came second, this can handle up to 54mbits and runs in the 5 GHz band, this has until recently been the domain of the corporate network as 802.11a equipment costs more to purchase and gives greater range.
The most recent entry is 802.11g which is back on the 2.4 GHz band but can achieve the 54mbps of 802.11a and brings the benefits of the cost reduction in technology, if you are buying networking equipment 802.11g is the best option today as it is also backwards compatible with 802.11b although your connection will run at the speed of the slowest technology used.

Wi-Fi Technology - II

WiFi Uses
So that's how so the next logical question is why and perhaps how to implement wireless networking?
In the Home
Home networking is not fun, that is reflected in the number of homes that have cabled CAT5 networks today, few homeowners want to run cabling under floors and have unsightly connection boxes in each room that you might use a device. So wireless is a real answer offering the ability for a broadband internet connection to be shared between users in the home, perhaps mum using the PC, dad on a laptop in the garden while the kids hook up their play station upstairs. Its only a small step from sharing your internet connection to a full network, sharing a printer and even a music server with all your collection stored as MP3's
This is the area that has seen the wifi explosion the home is leading the take up of wireless equipment and coupled with the rapid uptake of broadband wifi growth is assured for the next few years.
For home networking it is important to understand the components, each device will need a wireless card or dongle, they in turn connect to the hub which can be one of 3 devices.
The Wireless Access point is simply a translation device that sits connected to your main PC and allows any wireless device to talk to it, this means that if that PC is off then so is everyone's internet connection. Next a Wireless router, this is similar to the access point but allows routing around the home network so 2 laptops can network even if the main PC is off, but again if the internet connection is through the main PC if its off then so is you web connection.
By far the most popular choice is a wireless router / modem, be careful to get the right modem either dial up, DSL or ADSL these allow you to network all of your devices and as long as the wireless hub is on any device can access the internet, commonly these will have an inbuilt firewall and some cabled connections.
In the Workplace
The workplace on the other hand is far more cautious, most offices already have a perfectly good and fast (at least 100mbits) network in place, so what benefits are there for wireless? In strict terms for desktop PC's there are few, but more and more workers are issued with laptops as standard. Those laptops will almost certainly have a wireless access card as standard and the new centrino technology for Intel means every laptop shipped has embedded wifi.
So of course it makes sense to use wifi, but security conscious businesses are not happy with the level of encryption offered by WEP alone and are layering extra security on top far beyond rolling updates of keys, this makes networks a nightmare to manage and thus restricts growth in this area.
We must also consider the number of devices in an office network there could be hundreds of devices trying to share the limited number of channels, then there are issues of where to site access points to work most efficiently. Its not all doom and gloom with good planning these can be overcome to fully extract the business benefits of wireless networks but it takes some guts to get started.
Next Steps for Wifi
While many industry pundits (of whom we do not claim to be one) talk of hot spots and longer ranges it seems likely that the next 12 months will bring wifi into new devices, first mobile phones will have wifi alongside Bluetooth then add wifi to MP3 players allowing them to stream. Longer term Wifi may become the defacto standard for connecting household electronics and automating your home, heard this before? well yes that was Bluetooth.
What's different about wifi, well its cheap, commonly available and understood and if you don't have it in your home maybe you should, this is a consumer led growth you should be part of it.

AMD Turion™ 64 X2 Dual-Core Mobile Technology

AMD Turion™ 64 X2 Dual-Core Mobile Technology Overview
AMD's most advanced family of dual-core processors made for mobility—delivering outstanding multi-tasking performance in thin and light notebook PC designs
Simultaneous 32- and 64-bit performance and designed to be compatible with the next generation 64-bit Windows operating system, Microsoft® Windows® Vista™.
Rich choices for customers of all kinds —long battery life, better security with Enhanced Virus Protection* , and designed for compatibility with the latest wireless and graphics technologies—today and tomorrow

Leading-edge Mobile Performance
AMD64 dual-core performance delivers exceptional multi-tasking and multi-threaded performance for both 32 – and 64-bit environments
Featuring AMD's innovative Direct Connect Architecture for leading-edge dual-core processor performance
HyperTransport™ technology boosts overall system agility so your applications are responsive and you get incredible performance
AMD Turion™ 64 X2 dual-core mobile technology featuring AMD Digital Media XPress™ delivers a rich experience on today's multimedia-enhanced software, enabling stellar performance and playback quality on digital entertainment such as games, streaming video and audio, DVDs, and music
As a leading innovator in today's microprocessor technologies AMD products offer lasting reliability and cutting-edge technology

Enabling Your Mobile Lifestyle
Uniquely optimized to support today's innovative thin & light notebook designs empowering highly mobile business professionals and consumers living today's on-the-go lifestyle
AMD PowerNow!™ technology , the first dynamic power management technology in the industry, delivers performance on demand and can extend system battery life up to 65%
Compatible with currently available 802.11a, b, g, and Bluetooth wireless solutions, AMD Turion 64™ X2 mobile technology enables mobile PC users with integrated Wi-Fi certified WLAN technology to keep in touch. Anywhere mobile users go—from the airport, to poolside, to a remote office location—they can access the Internet, check e-mail, and stay connected

Richer Choices
Allows customers to choose among the best in wireless connectivity, graphics, and security
Renowned industry innovator AMD collaborates with industry-leading technology companies to bring you a powerful notebook with the exceptional performance and mobility you expect
*Enhanced Virus Protection (EVP) is only enabled by certain operating systems, including the current versions of Microsoft® Windows®, Linux®, Solaris, and BSD Unix. After properly installing the appropriate operating system release, users must enable the protection of their applications and associated files from buffer overrun attacks. Consult your OS documentation for information on enabling EVP. Contact your application software vendor for information regarding use of the application in conjunction with EVP. AMD strongly recommends that users continue to include third-party antivirus software as part of their security strategy.

EDI - Electronic Data Interchange

EDI - Electronic Data Interchange - is defined in this context as the exchange of transaction messages from computer to computer, using structures based on a recognised national or international standard.
Early developments of EDI were driven primarily by large buying organisations - supermarkets, chain stores, health services - which had the financial muscle to influence their trading partners to adopt a standard method of electronic trading, initially largely to the benefit of the buyer, though ultimately with benefits for both sides. The typical application would be based on a “hub and spoke” model, the hub being the buying organisation, and the spokes its suppliers. Messages would be transported over dial-up or, for large users, leased line connection, to a value-added network (VAN), using proprietary protocols for assuring integrity, security and end-to-end audit trail. Each party would have a mailbox on the VAN.
The economics of this form of communication would certainly involve a volume charge for communication, so that the message standards aimed for conciseness, the fullest possible use of coded data, and minimal use of text.
Since the real payoff from EDI came not just from more efficient communication, but also from faster and more efficient processing and turnround of transactions at each end, it was important that a message could be processed automatically, and this was and is another powerful factor favouring coded data rather than text.
Early applications did nothing more than automate the existing way of doing simple transactions like orders, delivery notes and invoices, so that the benefits came from speed, accuracy, removal of duplicate keyboarding and elimination of paper and postage. More sophistication has crept in as companies have realised that continuous electronic communication between supplier and customer can bring additional benefits, eg by anticipating and planning for demand rather than waiting for orders, or even by allowing the supplier to take control of the maintenance of appropriate stock levels in stores (so-called “vendor-managed inventory”).
The consequence of the widespread adoption of EDI messaging standards - now increasingly focused on EDIFACT - is that there is an equally wide range of software and systems available to support their use. Most commercial users do not develop their own EDI front-ends. They buy in a package which typically handles mapping between the EDI standard and internal file formats defined by the user; the management of trading partner relationships, by maintaining a database of who’s who and what messages are enabled as part of the trading agreement; and the timetabling and automatic running of online sessions to send and receive messages.
Increasingly, the Internet is now being used for sending and receiving EDI messages, either by FTP or by email transfer. A simple MIME for encapsulating an EDIFACT message was defined as long ago as 1995 ; and, under the aegis of the Internet Engineering Task Force, a much more comprehensive standard is being finalised which is claimed to enable an EDI message to be sent over the Internet with the same levels of security and audit trail which the Value Added Networks have traditionally provided

Simple Object Access Protocol - SOAP

A group of vendors from Microsoft, IBM, Lotus and others, created an XML-based protocol that lets you activate applications or objects within an application across the Internet. In a nutshell, SOAP codifies the practice of using XML and HTTP to invoke methods across networks and computer platforms.
What does this really mean?
With distributed computing and Web applications, a request for an application comes from one computer (the "client") and is transmitted over the Internet to another computer (the "server"). There are many ways of doing this, but SOAP makes it easy by using XML and HTTP - which are already standard Web formats.
Web Applications
Web applications are where SOAP really comes into its own. When you view a Web page you are using a Web browser to query a Web server and view a Web page. With SOAP, you would use your computer client application to query a server and actually run a program.
For Example
Right now, you might use online banking to access your bank accounts. My bank has the following options:
Online banking - account reviews, transfers, stop payment, etc.
Online bill paying
Online credit card management
While this bank has these three applications, they are all mostly separate. So if I go into the banking section I can't transfer funds from my savings account to my credit card, and I can't view my account balances while I'm in the online bill paying section.
One of the reasons that these three functions are separated is because they reside on different machines. I.e. the program that runs the online bill paying is one computer server, while the credit card and bill paying applications are on other servers. With SOAP, this doesn't matter.
You might have a method that gets an account balance: getAccount.
With standard Web based applications, that method is only available to the programs that call it and are on the same server. Using SOAP, you can access that method across the Internet via HTTP and XML.

How is SOAP Used?
There are many possible applications for SOAP, here are just a couple:
Business to Business integration - SOAP allows businesses to develop their applications, and then make those applications available to other companies
Distributed applications - programs like databases could be stored on one server and accessed and managed by clients across the Internet
One thing to consider when looking into implementing SOAP on your business server is that there are many other ways to do the same thing that SOAP does. But the number one benefit you'll gain from using SOAP is its simplicity. SOAP is just XML and HTTP combined to send and receive messages over the Internet. It is not constrained by the application language (Java, C#, Perl) or the platform (Windows, UNIX, Mac), and this makes it much more versatile than other solutions