0% found this document useful (0 votes)
108 views

Push Technology Documentation

Push technology delivers data to users without an explicit request, unlike the traditional pull model where users request updates. It provides data based on a user's profile and interests from various information channels. While push transfers control to data providers, it relieves users from constantly checking for updates across different sites. However, there are also concerns about receiving irrelevant data or abuse of the mechanism.

Uploaded by

Pavan bandi
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
108 views

Push Technology Documentation

Push technology delivers data to users without an explicit request, unlike the traditional pull model where users request updates. It provides data based on a user's profile and interests from various information channels. While push transfers control to data providers, it relieves users from constantly checking for updates across different sites. However, there are also concerns about receiving irrelevant data or abuse of the mechanism.

Uploaded by

Pavan bandi
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 24

0

INDEX

Sl. No. TOPIC Page. No


PAGE

1. ABSTRACT 1

2. INTRODUCTION 2

3. PUSH PHENOMENON 4

4. WORKING 7

5. CLASSIFIACTION OF DELIVERY MECHANISAM 9

7. OPTIONS FOR DATA DELIVERY 11

8. CUSTOMER SPECIFIC CHARACTERSTICS AND PROBLEMS 13

9. HTTP SERVER PUSH 16

10. ADVANTAGES 18

11. DISAVANTAGES 19

12. FUTURE SCOPE 21

13. CONCLUSION 22

14. REFERENCE 23
1

ABSTRACT

Push technology has recently generated a tremendous amount of media attention,


commercial activity, and controversy. The wide range of opinions on push is understandable
given that it represents a major departure from the way distributed information systems have
traditionally been built.
Adding to the noise, however, is confusion about the basic principles of push and where
it fits in to the world of data delivery. For example, many discussions on the topic blur the
distinction between push and broadcast.
We argue that this confusion stems from two fundamental causes: First, push is just one
dimension of a larger design space of data delivery mechanisms
Second, networked information systems can employ different data delivery options
between different sets of information producers and consumers.
In this short paper we characterize the design space for dissemination-based
information systems and applications, and show how current “push” solutions fit into this
space.
We then use this frame work highlight how the implementation of current Internetbased push
solutions differs from the appearance that they present to users.
2

INTRODUCTION

Push technology stems from a very simple idea. Rather than requiring users to explicitly request (i.e., “pull”)
the information that they need, data can be sent to users without having them specifically ask for it. The
advantages of push are straightforward. The traditional pull approach requires that.

This work has been partially supported by Rome Labs agreement number F30602-97-2-0241 under DARPA
order number F078, by the NSF under grant IRI-9501353, and by research grants from Intel and NEC. To
appear in the ACM SIGMOD International Conference on the Management of Data, Seattle, WA, June,
1998. users know a priority where and when to look for data or that they spend an inordinate amount of time
polling known sites for updates and/or hunting on the network for relevant sites.
Push relieves the user of these burdens.

The problems of push are also fairly obvious. Push transfers control from the users to the data
providers, raising the potential that users receive irrelevant data while not receiving the information they
need. These potential problems can arise due to issues ranging from poor prediction of user interests to
outright abuse of the mechanism, such as “spamming”.
3

The “in-your-face” nature of push technology is the root of both its potential benefits and disadvantages.
Push technology has been around in various forms for as long as people have been communicating.
Examples range from newspapers, to telephones, to radio and television, to E-mail. Early work on using
computer networks for pushing data was performed in the 1980’s.

The Boston Community Information System at MIT [Giff90], Teletext systems for distributing data over
broadcast media [Amma85, Wong88], and the Data cycle database machine [Herm87], are all examples of
systems that incorporated some form of push technology.

Recently, however, the combination of push technology with the Internet and Web (sometimes referred to as
Webcasting) has generated a ground swell of excitement, commercial activity, and controver.
4

PUSH PHENOMENON

In February 1996, PointCast made its client software available for free downloading over the Internet,
setting off a wave of interest in push technology. The idea was appealing: rather than using your idle desktop
machine as a display Ground for flying toasters, PointCast would turn it into an active information terminal
that would display headlines, weather forecasts, stock prices, sports scores, etc., with the appearance of
having real-time updates.

By specifying a profile, users could indicate their interests to the system, and the display would be tailored
to these interests. For anyone who tried the software, the reaction was immediate; this represented a
paradigm shift in the way one could think about using the Internet as an information delivery tool.

Push technology on the Internet represented a new and untapped medium. The computer trade press became
in undated with articles about push technology and dozens of companies touting push-based solutions
arrived on the scene.

A new jargon of data delivery was developed, with terminology borrowed from broadcast media. Users of
push technology could tune into channels that contained broadcasts of information on particular topics. By
the end of 1996, the excitement had spilled over into the mainstream press.
5

A steady stream of articles about push technology appeared in venues such as the New York Times and the
Wall Street Journal. 1 In February 1997, Business Week magazine published a Special Report section
entitled “A Way Out of the Web Maze”, which argued that Webcasting could solve many of the Web’s
problems, such as information overload and the inability for users to find the data they need.

Similar sentiments were echoed by numerous vendors and technology pundits. The peak of the media hype
for push technology was reached in March of 1997 when the cover article of Wired magazine blared: “Push!
Kiss your browser goodbye”.

This article began by declaring: “Remember the browser war between Netscape and Microsoft? Well forget
it. The Web browser itself is about to croak. And good riddance.”. While the article was certainly
provocative and clearly overstated, the argument it made was simply that push technology would change the
Web from a passive library of information into a networked, immersive medium for information and
entertainment delivery.

Despite this simple message, the article seemed to epitomize both the promise of push technology and the
potential for overselling its virtues
6
7

WORKING

Push technology or server push, is a style of Internet-based communication where the


request for a given transaction is initiated by the publisher or central server. It is contrasted
with pull/get, where the request for the transmission of information is initiated by the receiver
or client.

Push services are often based on information preferences expressed in advance. This is
called a publish/subscribe model. A client "subscribes" to various information "channels"
provided by a server; whenever new content is available on one of those channels, the server
pushes that information out to the client.

Push is sometimes emulated with a polling technique, particularly under circumstances


where a real push is not possible, such as sites with security policies that require rejection of
incoming HTTP/S requests.

Synchronous conferencing and instant messaging are typical examples of push


services. Chat messages and sometimes files are pushed to the user as soon as they are received
by the messaging service. Both decentralised peer-to-peer programs (such as WASTE) and
centralised programs (such as IRC or XMPP) allow pushing files, which means the sender
initiates the data transfer rather than the recipient.

Email may also be a push system: SMTP is a push protocol (see Push e-mail). However, the last
step—from mail server to desktop computer—typically uses a pull protocol like POP3 or IMAP.
8

Modern e-mail clients make this step seem instantaneous by repeatedly polling the mail server,
frequently checking it for new mail. The IMAP protocol includes the IDLE command, which
allows the server to tell the client when new messages arrive. The original BlackBerry was the
first popular example of push-email in a wireless context.

Another example is the PointCast Network, which was widely covered in the 1990s. It delivered
news and stock market data as a screensaver. Both Netscape and Microsoft integrated push
technology through the Channel Definition Format (CDF) into their software at the height of
the browser wars, but it was never very popular. CDF faded away and was removed from the
browsers of the time, replaced in the 2000s with RSS (a pull system.)

Other uses of push-enabled web applications include software updates distribution ("push


updates"), market data distribution (stock tickers), online chat/messaging systems (webchat),
auctions, online betting and gaming, sport results, monitoring consoles, and sensor
network monitoring
9

CLASSIFICATION OF DELIVERY MECHANISM

It is possible to classify many existing data delivery mechanisms using the characteristics
described above. Such a classification is shown in Figure 1. We discuss several of the
mechanisms below. Aperiodic Pull - Traditional request/response mechanisms use aperiodic pull
over a unicast connection. If instead, a 1-to-N connection is used, then clients can “snoop” on the
requests made by other clients, and obtain data that they haven’t explicitly asked ).

Periodic Pull - In some applications, such as remote sensing, a system may periodically
send requests to other sites to obtain status information or to detect changed values. If the
information is returned over a 1-to-N link, then as with request/response, other clients can snoop
to obtain data items as they go by.

Most existing Web or Internet-based “push” systems are actually implemented using
Periodic Pull between the client machines and the data source(s).

Aperiodic Push - Publish/subscribe protocols are becoming a popular way to disseminate


information in a network [Oki93, Yan95, Glan96]. In a publish/subscribe system, users provide
information (sometimes in the form of a al. [Imie94] depend on a strict schedule to allow mobile
clients to “doze” during periods when no data of interest to them will be broadcast.

3 Some systems attempt to implement a 1-to-N style of data delivery using unicast (i.e.,
by sending identical, individual messages to multiple clients).
10

As discussed in Section 3, this type of pseudobroadcast can result in tremendous


bandwidth and server overload problems. For this reason, we classify such systems as
“unicastbased” in our taxonomy.
1: Data Delivery Options profile) indicating the types of information they wish to receive.
Publish/subscribe is push-based; data flow is initiated by the data sources, and is aperiodic, as
there is no predefined schedule for sending data. Publish/subscribe protocols are inherently 1-to-
N in nature, but due to limitations in current Internet technology, they are often implemented
using individual unicast messages to multiple clients. Examples of such systems include Internet
e-mail lists and some existing “push” systems on the Internet.

True 1-to-N delivery is possible through technologies such as IP-Multicast, but such
solutions are typically limited to individual Intranets or Local Area Networks. Periodic Push -
Periodic push has been used for data dissemination in many systems.

An example of Periodic Push using unicast is Internet mailing lists that send out
“digests” on a regular schedule. For example, the Majordomo system allows a list manager to set
up a schedule (e.g., weekly) for sending digests. Such digests allow users to follow a mailing list
without being continually interrupted by individual messages. There have also been many
systems that use Periodic Push over a broadcast or multicast link. These include TeleText.
DataCycle , Broadcast Disks and mobile database
11

OPTIONS FOR DATA DELIVERY

Support for different styles of data delivery allows a distributed information system to be
optimized for various server, client, network, data, and application properties. We have identified
three main characteristics that can be used to compare data delivery mechanisms: (1) push vs.
pull; (2) periodic vs. aperiodic; and (3) unicast vs. 1-to-N. While there are numerous other
dimensions that should be considered, such as fault-tolerance, ordering guarantees, error
properties, network topology, etc.,

we have found that these three characacteristics provide a good initial basis for
discussing many popular approaches. In particular, we argue that all three of these characteristics
must be considered in order to make intelligent choices about delivery mechanisms for specific
situations.

Figure 1 shows these characteristics and how several common mechanisms relate to
them. 2.1.1 Client Pull vs. Server Push We first focus on push vs. pull. Current database servers
and object repositories manage data for clients that explicitly request data when they require it.

When a request is received at a server, the server locates the information of interest and
returns it to the client. This request-response style of operation is pull-based — the transfer of
information from servers to clients is initiated by a client pull. In contrast, as discussed in the
introduction, push-based data delivery involves sending information to a client population in
advance of any specific request. With push-based delivery, the server initiates the transfer. 2.1.2
Aperiodic vs.
12

Periodic Both push and pull can be performed in either an aperiodic or periodic fashion.
Aperiodic delivery is event-driven — a data request (for pull) or transmission (for push) is
triggered by an event such as a user action (for pull) or data update (for push). In contrast,
periodic delivery is performed according to some pre-arranged schedule. This schedule may be
fixed, or may be generated with some degree of randomness.
For the purposes of this discussion, we do not distinguish between fixed and randomized
schedules. Such a distinction is important in certain applications. For example, algorithms for
conserving energy in mobile environments proposed that sends out stock prices on a regular
basis is an example of periodic push, whereas one that sends out stock prices only when they
change is an example of aperiodic push. 2.1.3 Unicast vs. 1-to-N

The third characteristic of data delivery mechanisms is whether they are based on unicast
or 1-to-N communication. With unicast communication, data items are sent from a data source
(e.g., a single server) to one other machine, while 1- to-N communication allows multiple
machines to receive the data sent by a data source.3 Two types of 1-to-N data delivery can be
distinguished: multicast and broadcast. With multicast, data is sent to a specific subset of clients
who have indicated their interest in receiving the data.
Since the recipients are known, given a two way communications medium it is possible to make
multicast reliable; that is, network protocols can be developed that guarantee the eventual
delivery of the message to all clients that should receive it. In contrast, broadcasting sends
information over a medium on which an unidentified and possibly unbounded set of clients can
listen
13

CUSTOMER SPECIFIC CHARACTERSTICS & PROBLEMS

The inclusion of customers into “technology push” development projects in order to reduce the
great market uncertainty that exists as a result of a lack of market knowledge, often proves to be
problematic. It is often the case in technology induced development projects that it is not
completely clear exactly who the prospective customers are.
Those responsible for marketing in “market pull” innovations often possess very detailed
knowledge about the profile of their customers and their needs. In contrast, a key activity in
technology-induced innovation projects is the determination of the target market in question as
well as their preferences.
5 Even if the development project team develops an initial impression from potential
customers, the customers are often not able to articulate their preferences with regard to such an
abstract technology concept, as they lack experience with the technology’s potential applications
(the barrier of “missing skills”).
Even if the customers possess the required skills, psychological barriers exist (the barrier
of the “missing motivation”) accompanied by a completely different set of problems and where,
from the customer’s point of view, no requirement exists for them to be dealt with (Veryzer,
1998 a; O’Connor, 1998; Bower; Christensen, 1995).
In addition, technological innovations often bring with them the need for a change in
behavior for the customer that is often perceived as being “uncomfortable” by the customer and
makes intensive re-schooling unavoidable (Lynn et al. 1996; Urban et al, 1996).
14

If a project's future was to be determined therefore only on the basis of the customer’s
“voice”, then the result would often be the abandonment of the envisioned technology-driven
innovation project due to these cognitive and behavioral-related barriers encountered.
An example of this can be in the years where leading US radiologists adamantly advised
General Electric not to develop Computer Axial Topography any further, a technology that
would later and till this day is described as a breakthrough innovation (Lynn et al., 1996). Why?
The doctors questioned saw no need for a replacement for the traditionally used X-ray
technology.

GE fighting against not only an established technology with its CAT breakthrough but
also against decades-old behavioral patterns. New doctors were (are) learning to work with the
X-ray machines at university, and this knowledge accompanied (accompanies) these doctors
throughout their careers in their practical work as well as their research.
Another example is that of the US-company Corning, who succeeded with third
development of the “Optical Fiber” a breakthrough innovation, only because they ignored the
negative assessment of their most important customer, AT&T, and continued working on this
technology (Lynn et al., 1996).
Therefore the further away from market introduction a technology is the more difficult it
is to know when customers are “mature” enough for a technological innovation or when
problems from a technological point of view are eliminated.
From this, one could conclude that talks with target customers in the initial stages of a
technology-driven innovation with the aim of ascertaining there likely future product acceptance
and purchasing preparedness usually must lead to the termination of these sorts of projects.
15

In our opinion, this hypothesis goes too far; in this context, we consider the following
two questions to be of utmost relevance: 1. What contribution do customers, i.e. people who buy
and use products, make to a development –driven project and at what points in the overall
development process? 2.
Can companies profit significantly more from the inclusion of customers or users from
analogous application fields? Von Hippel, in the early 1980s, had already suggested the concept
of so-called Lead Users, who differ greatly, with respect to their innovation potential, in
comparison to average customer/users.
Von Hippel showed, through the example of the development integrated circuit that such
Lead User manufacturers can deliver pure consumer data as well as complete new product
conceptions and designs.

Von Hippel described these users through the following two characteristics
16

HTTP SERVER PUSH

HTTP server push (also known as HTTP streaming) is a mechanism for sending
unsolicited (asynchronous) data from a web server to a web browser. HTTP server push can be
achieved through any of several mechanisms.

As a part of HTML5 the WebSocket API allows a web server and client to communicate


over a full-duplex TCP connection.

Generally the web server does not terminate a connection after response data has been served to
a client. The web server leaves the connection open so that if an event occurs (for example, a
change in internal data which needs to be reported to one or multiple clients), it can be sent out
immediately; otherwise, the event would have to be queued until the client's next request is
received.

Most web servers offer this functionality via CGI (e.g., Non-Parsed Headers scripts
on Apache HTTP Server).

The underlying mechanism for this approach is chunked transfer encoding.

Another mechanism is related to a special MIME type called  multipart/x-mixed-replace , which


was introduced by Netscape in 1995.

Web browsers interpret this as a document that changes whenever the server pushes a new
version to the client.

It is still supported by Firefox, Opera, and Safari today, but it is ignored by Internet Explorer,and


is only partially supported by Google Chrome. It can be applied to HTML documents, and also
for streaming images in webcam applications.

The WHATWG Web Applications 1.0 proposal includes a mechanism to push content to the


client. On September 1, 2006, the Opera web browser implemented this new experimental
system in a feature called "Server-Sent Events". It is now part of the HTML5 standard.
17
18

ADVANTAGES

 Performance measurement.The push system enables corporate planners to leverage the


total channel historical demand to meet shipment goals while minimizing channel
inventories. Performance is measured not just on the success of discrete stocking points,
but on how well the whole channel is meeting corporate sales and asset management
targets.

 Central planning. By centralizing all inventory planning and replenishment allocation,


channel planners can create a single inventory plan for the ongoing ordering and
deployment of channel inventory. Central planning enables planners to determine global
channel inventories and to remove the normal supply point stock redundancies caused by
inaccuracies in local replenishment decision making. In addition, by strategically
deploying inventory resources throughout the channel (risk pooling), stocking
inequalities among branches is reduced, further cutting costs and dampening risk arising
from interbranch transfer and lost customer sales.

 Cost reductions. By centralizing inventory planning and deployment, companies can


reduce the total working capital necessary to stock the supply channel. In addition,
operating costs are reduced by economies attained in transportation and purchasing.
Instead of ordering products to satisfy individual branch demand, central purchasing can
combine requirements from all branches, thereby reducing inbound transportation and
acquisition costs while gaining quantity price breaks and other order discounts. In
addition, the presence of costly inventory planners and planning functions can be
removed from satellite warehouses.

 Safety stock control. Whereas safety stock is a characteristic feature of inventories


subject to independent demand, a "push" system enables planners to centralize safety
stocks at the central facility. By eliminating unnecessary safety stocks carried at each
channel location, “push” systems reduce total inventory costs while maintaining high
channel serviceability.
19

DISADVANTAGES

Disadvantages of a push system center on organizational issues.

An effective push system requires a professionally trained central planning staff that can work
with aggregate data and demand forecasting techniques. In addition, inventory accuracy and
timely transaction record posting normally requires a computer system that enables the
networking of the historical demand resident at each channel location.

Another serious problem is possible inventory imbalances in the supply chain as sales at local
supply points deviate from plan. Finally, the introduction of a push system requires changes in
operational roles. As central planning is now responsible for resupply planning and execution,
branch management's role migrates from a focus on detailed inventory replenishment
management to ensuring transmission of accurate stock status and sales usage information to the
channel's central planning functions.

While the level of variation is very high depending upon the business environment,
companies/products using a push system would mostly likely fall under the following categories:
20

 Inexpensive commodities with low demand uncertainty that must pass through many
distribution channel echelons before they reach the end-customer. Think of a beverage
such as Coca-Cola that moves down a complex delivery channel, often spanning many
intermediaries before it reaches the retail marketplace.
 Food products such as bakery items, meats, and produce that have very narrow shelf-life
windows governing when they can be sold. When the effectivity dates are reached,
remaining inventory is unsellable and normally disposed of at a loss.
 Fashion apparel that is seasonal in nature. Normally, women’s fashions do not repeat
from one year to the next. Getting such products to market requires precise
predetermining of product allocations. Missing one day of a new season could result in
significant loss of revenue and customer loyalty.
 Products subject to short-lived promotional campaigns and special deals. An example is
this month’s new best-selling book.
 Products with long production run times or are produced in large lots.

In the next blog I will be exploring the nature and function of “Pull” systems of inventory
replenishment
21

FUTURE SCOPE

 The product terrain of the Push Notifications Software market is categorized into
o Cloud-based
o On-premises
 Revenue and volume predictions for each product type is cited in the study.
 Projections for the growth rate, market share, and production patterns of each product
category over the analysis period are validated.
 The application spectrum of the Push Notifications Software market is split into

o PC Terminal
o Mobile Terminal
 In-depth company profiles with respect to product portfolio, market remuneration,
production patterns are underlined, pricing model, and industry share.
 Latest updates pertaining to the evolving competition trends are explained.
 Analytical review of the industry supply chain is furnished in the research document.
 The study also leverages Porter's Five Forces and SWOT analysis tools to determine
the feasibility of a new project.
22

CONCLUSION

push technology. Push technology provides benefits such as reducing and managing the
information overload and dealing with communication bandwidth bottlenecks. In addition, push
technology can also easily develop an extranet solution by integrating webcasts into one’s
broadcasts.
Some of this is seen today by subscribers to cable channels using such technology through
network channels such as CNN and MSNBC. Push technology allows one to broadcast unique
information by integrating one’s network directory service.
Push technology makes the online experience more convincing and responsive to the needs of
one’s clients. Push technology is an important chemistry to push and integrate future computer
communication. This chemistry cannot be complete without management’s support,
commitment, and future vision of a global electronic commerce environment. For the IT
professional and manager, this is a new step and horizon for which communication and
teamwork with the users are key components.
It can provide business with the competitive edge needed to survive.
Global competition pressures have set the tone for the evolution of push technology. Those who
accept the risk, plan, and communicate and work together can make it successful for the
business.
23

REFERENCES

1.  M. Thomson, E. Damaggio and B. Raymor (October 22, 2016). "Generic


Event Delivery Using HTTP Push". Internet Draft. Internet Engineering
Task Force. Retrieved October 28, 2016.
2. ^ "Web Notifications".
3. ^ "Web Push API".
4. ^ CGI Programming on the World Wide Web O'Reilly book explaining how
to use Netscape server-push
5. ^ Server-Push Documents (HTML & XHTML: The Definitive
Guide) Archived 2008-04-17 at the Wayback Machine O'Reilly book
explaining server-push
6. ^ Remove support for multipart/x-mixed-replace main resources
7. ^ "Web Applications 1.0 specification".
8. ^ "Event Streaming to Web Browsers". 2006-09-01. Retrieved 2007-03-
23.
9. ^ "Opera takes the lead with AJAX support among browsers: More
efficient streaming". 2006-09-01. Archived from the original on 2007-03-
18. Retrieved 2007-03-23.
10. ^ "HTML Standard – Server-sent events". html.spec.whatwg.org. 31
March 2022. Retrieved 1 April 2022

You might also like