With Unicast, the
traffic generated is proportional to the number of receivers.
It generates a very important network load and is unsuitable for
large-bandwidth transmissions.The Service Location Protocol
A Multicast Application
Project Director :
Philippe Dax
dax@inf.enst.fr
Version as of Saturday, July 06, 1996
Document Copyrighted ©
Matthieu Cornillault, 1996
Special Thanks to
Erik Guttman (Sun Microsystems) and
Philippe Dax (ENST Paris) our Multicast guru.
MBONE could be defined as the Multimedia Backbone. It could soon be a good way for an on-line classroom with students from different countries, or participating in an important videoconference with researchers from around the globe.
So far, MBONE has been making its way in the Internet
slowly and experimentally. There are about 1,700 networks in about
20 countries on the MBONE. This means that MBONE is only available
in 3% of the Internet. MBONE expansion has been reduced by the
hardware and software costs incurred. Anyway, the advances in
bandwidth and compression technologies could make MBONE possible
on more networks, and thus could make of MBONE one of the largest
bandwidth user.
The traditional Internet transmission system is based on Unicast : one person (or computer) sends an information to one person at a time. Every packet has a single destination, would it be by email, web or any other application. Even though computers can send millions of request per second, they will be only one person sending and one person receiving at a time.
When you want to send an information to several people, here is what happens : let say you want to send an email to 20 of your friends, then the email will go to the first one, then to the second one, and will take the same amount of bandwidth for each of them. It will take 20 times as much Internet traffic. Attaching a graphics file to your email would make the effect 20 times worse than when sending one email. Let say a rock group wants to broadcast his concert to thousands of fans... you can easily imagine how fast the Net will be saturated.
That's why MBONE is here. It permits " IP Multicasting ". This technique allows packets to be broadcasted to anyone listening rather to a single individual. The packets are not sent to each recipient but they end up to all specified destinations.
Multicast is to Internet what Broadcast is to local networks. When a computer wants to talk to all the computers on its local networks, it can use the broadcast address. But broadcast queries are stopped by routers. Like TVs that broadcast shows, anyone at his home can switch on his TV and get to the good channel to get the show. It's exactly the same with multicast : selecting the good multicast channel will allow you to receive the information that has been multicasted on this channel.
This way, you can broadcast your voice with multicast
to anyone who wants to listen and the people listening can also
reply to everyone the same way.
With Unicast, the
traffic generated is proportional to the number of receivers.
It generates a very important network load and is unsuitable for
large-bandwidth transmissions.
With the broadcast,
the packet is emitted only once, and received by all machines
on the local network. In this example, Computer 1 is broadcasting
an information : Computers 1,2,3 and 4 will receive it but
the router will stop it. The broadcast address associated to the
device emitting the packet will be used for this transmission.
(If the local network address is 192.68.98.0, the broadcast address
will probably be 192.68.98.255).
With Multicast, the
information is not duplicated between 2 routers. No matter how
many people will be listening to the emission,the bandwidth used
won't be proportional to the number of people listening. To do
this, a Class D Multicast Address is used. (see paragraph about
Multicast Addresses).To use Multicast you need to have the right hardware and software equipment, and also enough bandwidth.
MBONE is a virtual network layered on the physical networks that support Multicast. The virtual Point-to-Point links that connect two physical networks is called a " tunnel ". Each point has to run the " mrouted " multicast routing daemon.
The mrouted daemon sources can be found at :
ftp ://gregorio.stanford.edu/vmtp-ip/ipmulticast.tar.Z
ftp ://gregorio.stanford.edu/vmtp-ip/ipmulti-sunos41x.tar.Z
ftp ://gregorio.stanford.edu/vmtp-ip/ipmulticast-ultrix4.2a-binary.tar
IP Multicast packets are encapsulated in normal Unicast datagram packets, so that they are transmitted like regular UDP/IP packets. The protocol field in this new IP header will indicate that the encapsulated packet is also an IP packet.
When the multicast router at the other end receives this packets, it decapsulates the packets and emits on its networks the multicast packet.
We can avoid the use of tunnels if the routers can route IP multicast directly.
The following map represents the major routers of MBONE. We can observe that the topology of MBONE is done of stars inside regions and of meshes between these regions. Some links can be redundant for most robustness.
Other maps can be found at Xerox Park :
ftp ://parcftp.xerox.com/pub/net-research/mbone-map-big.ps
ftp ://parcftp.xerox.com/pub/net-research/mbone-map-small.ps
ftp ://ftp.isi.edu/mbone/mbone-topology.ps
Each regional network is coordinated with the other regional networks through mailing lists. New participants can contact the right mailing list very easily.
How to join the MBONE :
Australia : mbone-oz-request@internode.com.au
Austria : mbone-at-request@noc.aco.net
Canada : canet-mbone-request@canet.ca
Denmark : mbone-request@daimi.aau.dk
France : mbone-fr-request@electre.inria.fr
Germany : mbone-de-request@informatik.uni-erlangen.de
Italy : mbone-it-request@nis.garr.it
Japan : mbone-jp-request@wide.ad.jp
Korea : mbone-korea-request@cosmos.kaist.ac.kr
Netherlands : mbone-nl-request@nic.surfnet.nl
New Zealand : mbone-nz-request@waikato.ac.nz
Singapore : mbone-sg-request@technet.sg
United Kingdom : mbone-uk-request@cs.ucl.ac.uk
Europe : mbone-eu-request@sics.se
North America : mbone-na-request@isi.edu
Other : mbone-request@isi.edu
There are 4 type of addresses :
There are 127 network of class A. Each of them represents 16 millions of machines. The first bit of the IP address of these machines is a 0.
Examples :
16.0.0.0 (DEC)
There are 16384 networks of class B. Each of them represents 65534 machines. The fist two bits of the IP address are 10.
Examples :
129.104.32.2 (olympe.polytechnique.fr)
129.104.0.0 (Polytechnique)
There are 2 millions of networks of class C. Each of them represents 254 machines. The first 3 bits of the IP address are 110.
Examples :
192.48.98.14 (sil.polytechnique.fr)
192.48.98.0 (Polytechnique)
There are 250 millions of class D addresses. The first 4 bits of their address is 1110.
Multicast addresses are Class D addresses.
Examples :
224.0.1.22 svrloc.mcast.net
224.0.1.35 svrloc-da.mcast.net
RFC 1112 defines the Internet Group Membership Protocol (IGMP). IGMP specifies how the host should inform the network that there is a member of a particular multicast group.
RFC 1075 defines the Distance Vector Multicast Routing Protocol (RVMRP). DVMRP uses a technique known as Reverse Path Forwarding. When a router receives a packet, it floods the packet out of all paths except the one that leads back to the packet's source. If a router is attached to a set of LANs that doesn't want to receive a particular multicast group, the router can send a " prune " message back up the distribution tree to stop subsequent packets from traveling where there are no members.
DVMRP has been used to build the MBONE by building tunnels between DVMRP-capable machines.
RFC 1584 defines the Multicast Open Shortest Path First (MOSPF) protocol, an extension to OSPF that allows it to support IP multicast. OSPF works by having each router in a network understand all of the available links in the network. Each OSPF router calculates routes from itself to all possible destinations.
MOSPF is best suited for environments that have relatively few source pairs active at any given time. It will work less well in environments that have many active sources or environments that have unstable links.
Two Internet standards-track drafts describe PIM, a multicast protocol that can be used in conjunction with all unicast IP routing protocols. These documents are entitled Protocol-Independant Multicast (PIM) : Motivation and Architecture and Protocol-Independant Multicast (PIM) : Protocol Specification.
PIM supports two different types of multipoint traffic distributed patterns : dense and sparse.
Dense mode is useful when :
Sparse mode is useful when :
PIM is able to support dense mode and sparse mode in the same time for different multipoints groups.
RIP is defined by RFC 1723. With the advent of OSPF,
there are those who believe that RIP is obsolete. While it is
true that the newer IGP routing protocols are far superior to
RIP, RIP does have some advantages. Primarily, in a small network,
RIP has very little overhead in terms of bandwidth used and configuration
and management time. RIP is also very easy to implement, especially
in relation to the newer IGPs.
RTP is a thin protocol providing support for applications with real-time properties, including timing reconstruction, loss defection, security and content identification. RTCP provides support for real-time conferencing for large groups within internet, including source identification and support for gateways (like audio and video bridges) and multicast-to-unicast translators. RTP can be used without RTCP if desired. While UDP is its initial target for a networking environment, efforts have been made to make RTP transport-independant so that it could be used, say over CLNP, IPX or other protocols. RTP is currently in experimental use over AAL5/ATM. RTP does not address the issue of resource reservation or quality of service control. Instead, it relies on resource reservation protocol such as RSVP.
MTP is defined by RFC 1301. MTP is a flow controlled,
atomic multicasting transport protocol. In addition to transporting
data reliably and efficiently, MTP provides the synchronization
necessary for web members (a web is a collection of processes)
to agree on the order of receipt of all messages and can agree
on the delivery of the message even in the face of partitions.
RMP is a protocol based of the Reliable Multicast
Protocol proposed by Chang and Maxemchuk. RMP provides an atomic,
totally ordered, reliable multicast service on top of IP Multicasting.
RMP is a testbed for verification efforts involving highly complex
distributed applications.
RSVP is a network control protocol that will allow
Internet applications to obtain special qualities-of-service (QoS's)
for their data flows. This will generally require reserving resources
along the data paths. RSVP is a component of the future integrated
services Internet, which will provide both best-effort and real-time
qualities of service. When an application in a host requests a
specific QoS for its data stream, RSVP is used to maintain router
and host state to provide the requested service. Although RSVP
was developed for setting up resource reservations, it is readily
adaptable to transport other kinds of network control information
along data flow paths.
The TTL (Time To Live) defines the range of the packet validity. It is usually defined according to the following map :
The TTL value decrements by one each time the packet goes through a router. So, the TTL value would be the maximum number of routers to go through. However, the tunnels are configured to respect the following table :
| 1 | Local Network |
| 32 | Site |
| 48 | Country |
| 64 | Continent |
| 128 | World |
VAT 4.0 is an audio conference tool available at
ftp ://ftp.ee.lbl.gov/conferencing/vat/alpha-test/vat-4.0*
NEVOT is an audio conference tool available at
ftp ://gaia.cs.umass.edu/pub/hgschulz/nevot
NETVIDEO is a video conference tool available at
ftp ://parcftp.xerox.com/pub/net-research/nvbin-3.3-*
IVS is a video conference tool available at
ftp ://zenon.inria.fr/ivs/rodeo/ivs/version3.3m3/ivs3.3m3-*
VIC 2.7 is a video conference tool available at
ftp ://ftp.ee.lbl.gov/conferencing/vic/alpha-test/*-vic-bin-2.7.*
WB is a shared white board tool available at
ftp ://ftp.ee.lbl.gov/conferencing/wb/wb-1.57*
IMM is a JPEG images tool available at
ftp ://ftp.hawaii.edu/paccom/imm-3.3/imm-*
SD is a session directory Rendezvous tool available at
ftp ://ftp.ee.lbl.gov/conferencing/sd/sd-1.13*
MMCC is a Rendezvous software available at
ftp ://ftp.isi.edu/confctrl/mmcc/
Mmphone is a Rendezvous software available at
ftp ://ftp.eit.com/software/mmphone/phoneform.html
Multicast Reflector was developed by ACM at UIUC. It is available at :
ftp ://www.acm.uiuc.edu/signet/projects/reflect.html
A version of the Multicast Reflector was developed by Cornell and is available at :
ftp ://gated.cornell.edu/pub/video/Reflector/
Mac and PC applications don't support Multicast yet. But the following applications are expected to support it one day.
Cu-SeeMe is a video conference tool available at
ftp ://gated.cornell.edu/pub/video/MAC.Cu-SeeMe*
and ftp ://fated.cornell.edu/pub/video/PC.CU-SeeMe*
Maven is an audio conferencing tool available at
ftp ://k12.cnidr.org/pub/Mac/Dir-Soundstuff/Maven-*
Some good FTP Sites for Multicast Softwares :
SGI : ftp ://ftp.sgi.com/sgi/ipmcast/
Solaris : ftp ://ftp.uoregon.edu/pub/Solaris2.x/src/MBONE/Solaris2.x/binaries
Solaris : ftp ://playground.sun.com/pub/multicast/
DEC-Alpha running OSF1 V2.0 : ftp ://chocolate.pa.dec.com/mbone/
FreeBSD 2.1/NetBSD : ftp ://ftp.parc.xerox.com/pub/net-research/ipmulti/
HP/UX 9.05 : ftp ://ftp.parc.xerox.com/pub/net-research/ipmulti/
Linux : ftp ://andrew.triumf.ca/pub/linux/multicast-FAQ
SLP : The Service
Location Protocol
As of Version 1.4 (June 14th 1996)
The Service Location Protocol is meant to help users to find services on a network. Services can be anything from a printer, to a web server or a ftp server.
The request is given this way :
LPR ://(& (PAGES PER MINUTE==12) (UNRESTRICTED_ACCESS) (LOCATION==2nd FLOOR))/
This request means that we are looking for printers that can handle 12 pages per minutes, that have an unrestricted access and that are located on the 2nd floor.
The reply could be the following :
URL : SERVICE :LPR ://ULYSSE.ENST.FR :515
ATTRS : ((PAGES PER MINUTE=6,12),(PROTOCOL=LPR,PCNFS),UNRESTRICTED_ACCESS,(LOCATION=2nd FLOOR))
This way, every user can find an answer to his request in a very quick time.
There are 3 mains actors. The User Agent, controlled by the end users, the Service agent, controlled by the Services and the Directory Agent, controlled by the System Administrator. In terms of client/server, the Directory Agent would be the server. The Service Agent would be the client that modifies and sends information to the server. The User Agent would be the client that requests the information.
The Service, in itself can be anything from a printer, to a web server or a ftp server. A scanner or even a coffee machine could be considered as a service.
Right now, services are located with the help of the DNS. (Domain Name Server). For example, the FTP server will be named or aliased ftp.enst.fr. That works for almost everything that is connected to the network. But it does not tell much about the service in itself. If the user needs a printer that does 6 pages per minutes, that has blue paper and that is located in such or such building, the DNS won' t be able so far to answer this request.
SLP can because it has been created for that. SLP has a notion of service and has also a notion of attributes. Moreover, SLP can change very quickly, much quicker than for a DNS change. SLP is very easy to configure. It needs no prior knowledge of the network configuration. It discovers everything with the help of multicast.
Here is a definition of the different actors :
The user agent is a process working on the user's behalf to acquire service attributes and configuration. The user agent retrieves service information from the service agents or directory agents.
The service agent is a process working on behalf of one or more services to advertise service attributes and configuration. It may or may not listen to UA requests.
The Directory Agent is a process which collects information from service agents to provide a single repository of service information in order to centralize it for efficient access by User Agents. There can only be one DA present per given host.
SLP comes from an IETF draft. This draft defines the behaviors of each actors.
In terms of protocol, each actor has a particular role to play. Each of them is detailed in this section. All the different tasks define their roles. The interaction of the actors is done with the use of grammars. The user agent uses a grammar to make its request, and so does the Service Agent. The grammars have not been reproduced in this document but can be found in the IETF draft.
Every packet sent and received is started by a header, called PDU Header. This header tells what function is used in the rest of the packet. The structure is the following :
| 0 31 | ||||
The Version is to be always set to 1.
The Function can be one of the following :
| Service Request | 1 |
| Service Reply | 2 |
| Service Registration | 3 |
| Service Deregistration | 4 |
| Service Acknowledge | 5 |
| Attribute Request | 6 |
| Attribute Reply | 7 |
| DA Advertisement | 8 |
| Service Type Request | 9 |
| Service Type Reply | 10 |
Another structure used by the protocol is the URL Entry. It associates a lifetime to an URL :
| 0 31 | |
A URL String is conform to RFC 1738. It must be similar to :
The Request has the following structure :
| 0 31 | |
The grammar is conform to :
Examples :
printer ://(LOCATION==C221)/
means that we are looking for a printer located in room C221.
printer :/INF/(& (PAGES PER MINUTE==6) (PAPER COLOR==WHITE))/
means that we are looking for a printer, which is in the Scope of Department INF, and which does 6 pages per minutes, and which has white paper.
directory-agent :///
is a special request that permits the Directory Agent
Discovery. The reply is done with a DA Advertisement.
The DA Advertisement is sent by the Directory Agent, in reply to a DA Discovery, or periodically to advertise. Its structure is the following :
| 0 31 | |
The structure of the Service Reply is the following.
It uses the URL Entry Structure.
| 0 31 | |
| |
The Service Type Request has the following structure :
| 0 31 | ||
| ||
The Service Type Reply has the following structure :
| 0 31 | |
| |
The Service Type Item is an item of the Service Type Reply :
| 0 31 | ||
A reply could be :
224.0.3.10 SERVICE :LPR ://
224.0.3.24 SERVICE :HTTP ://
224.0.3.115 SERVICE :NFS ://
The Service Registration Structure is the following :
| 0 31 | |
The Service Deregistration has the following structure :
| 0 31 | ||
The Attribute Request has the following Structure :
| 0 31 | ||
The Attribute Reply has the following Structure :
| 0 31 | |
The Service Acknowledge has the following structure :
| 0 31 |
In this example, we want to see how a user can get a simple reply to his question : " Where can I find a printer available in the Scope (Department) CAL ". To answer this question, we have to see that this service (the printer) has been registered.
The process of this request is split in different actions :
The service knows about itself :
The service daemon makes a DA Discovery. The discovery is done in multicast.
All the DA present reply. The Service is sure to
have all replies, through the convergence mechanism. Replies are
done is multicast.
Once the DA are discovered, the Services can unicast
their registrations to the DAs.
The DAs send an acknowledge packet to confirm the
registration (or to specify the type of error that occurred)
The user emits DA Discovery frames to detect DAs. (in multicast)
Each reached DA replies to the user, using DA Advertisement
frames.
Only morgon.enst.fr (in this example) has the right
scope. So the user will query morgon.
The queries are done in unicast, directly between
the DA and the user.
The DA morgon.enst.fr has a reply to the request. It sends it to the user :
This way, the user has now the answer to his question :
printer ://ulysse.enst.fr :415
SCOPE=INF,CAL
As of Saturday, July 06, 1996
The SLP protocol is a new protocol that is described in an IETF draft. This draft has been changing from version 1.0 (when I came to the project) to version 1.4.
The protocol and its evolution are discussed in the mailing list srvloc@tgv.com. Subscribing to this mailing is the first thing I did at the beginning of the project. After a few posts, I came in contact with the people involved in this project :
The protocol is written under the name of 4 people :
John Veizades, @Home Network (veizades@home.net)
Erik Guttman, Sun Microsystems (eguttman@eng.sun.com)
Charles Perkins, IBM Research (charliep@watson.ibm.com)
Scott Kaplan.
The people active on the mailing list were Erik and Charles. Erik was very helpful, replying very quickly to each of my emails. I found them very interested by my working on the project. Several people - including myself - are working on different implementations of this protocol.
I started reading the draft to understand it. At the beginning, the draft was not as clear as today, and it took some time to understand how it was working.
I started by reading multicast documentation since I had no knowledge of multicast. Finding information on making multicast programs was not easy since most books don't talk about it.
Then I made my first multicast programs, to make sure it would work. After this was done, I decided to start the " DA Discovery ". In order to do so, I made a tiny Directory Agent and a Tiny Client.
My second step was to make the Service Registration and Deregistration. (which was called unregistration at that time). This made my Directory Agent a bit bigger.
The next big step was to implement the grammars. I had used grammars before, but only under CAML (functional language) so I was wandering how to do it. Making it in C from scratch didn't seem reasonable because the grammar was quite complex. So I decided to learn Yacc and Lex. After a few nights working on it, I had my first grammar.
In fact, everything was going on its way, until this
day around the 10th of June when I received this phone-call.
I was quite surprised to hear Erik on the phone. He was telling me that they were planning some changes in the protocol. So far, the protocol was quite complex and the IESG asked them to make it clearer. Of course, this was meaning important changes in my work, so they wanted to have my opinion about it. I agreed on the need of making the protocol clearer.
The final protocol came on June 14th after a long bug hunt, and the numerous emails we sent one to another.
So I finally received this email :
From charliep@watson.ibm.com Thu Jun 13 21:25:10 1996
To: eguttman@osmosys.incog.com (Erik Guttman)
Cc: veizades@home.net, mc@netsurf.org
Subject: Re: last final no more changes (after these :-)
Date: Thu, 13 Jun 96 15:19:03 -0500
Status: RO
Here it is. I'll wait another hour to submit it, in case
you find something else
of interest.
Charlie P.
This important and necessary change made me loose a couple of weeks (working almost 24 hours a day).
I finally came to writing 4 different grammars, for
the different types of request I needed.
The plans are to keep on working during the summer and make the first interoperability testing at the end of August. Let's hope it will work !
What follows is a list of requirements for each actor.
Each requirement is told to be done, not done or partially done.
This shows the evolution of the implementation.
So far, the directory agent does the following :
must be able to send unsolicited Directory Agent Advertisements to the Service Location General Multicast address on startup and repeat it periodically. This reply has a unique XID for the life of the DA . If the DA starts with state, it initializes the XID to 0x0100. If it starts up stateless, it initializes the XID to 0x0000.
Partially Done.
Still to be done :
must be able to listen to the Directory Agent Multicast Address for Discovery agent discovery requests. Filter these requests if the Previous Responder Address Specification list includes the DA's address Specification.
Done.
must be able to listen to broadcast requests on the Service Location port.
Done.
must be able to listen on the TCP and UDP Service Location ports for unicast requests, registrations and deregistrations and service them.
Done.
must be able to provide a way in which SCOPE information can be used to configure the Directory Agent.
Done.
must be able to age out the services which have been registered so that when the service registration's TTL expires, the service advertisement is withdrawn.
Partially Done.
must ignore any unauthorized Service Location messages when an appropriate IPSec Security Association exists for that request.
Not Done.
must use the IP authentication and IP Encapsulating Security Payload in Service Location messages whenever an appropriate IPSec Security Association exists.
Not Done.
must accept requests and registrations in US-ASCII.
Done.
may ignore any unauthorized Service Registrations or Service Deregistration.
Not Done.
may accept registrations and requests in non-US ASCII character encodings. This in encouraged, especially for UNICODE and UTF-8 encodings.
Not Done. ( ?)
must be able to unicast requests and receive replies from a DA. Transactions should be made reliable by using retransmission of the request if the reply does not arrive within a timeout interval.
Partially Done.
must be able to detect DAs using a Directory Agent Discovery request issued when the UA starts up.
Done.
must be able to send requests to a multicast address. If the multicast address is not known, the UA must be able to use a Service Type query to obtain the multicast address for the service type of the request.
Not Done.
must be able to handle numerous replies after the multicast request. The implementation may be configurable so it will either return the first reply, all replies until a timeout or keep trying till the result converge.
Partially Done.
must ignore any unauthenticated Service Reply or Attribute Reply when an appropriate IPSec Security Association for that Reply exists.
Not Done.
must use the IP Authentication Header or IP Encapsulation payload in all service Location messages, whenever an appropriate IPSec Security Association exists.
Not Done.
must be able to issue requests using the US-ASCII character set.
Done.
should listen to the Service Location General Multicast address for unsolicited Directory Agent replies. This will increase the set of directory agent available to it for making replies.
Not Done. (problem
if several processes listen to the same address ?)
may provide a way for the application to configure the default DA, so that it can be used without needing to find it initially.
Not Done.
may be able to request the address of a DA from DHCP, if configured to do so.
Not Done.
may be able to request the issue requests in any language or character set provided that it can switch to the default language and character set if the request can not be serviced by DAs and SAs at the site.
Not Done.
must be able to listen to the Service Location General Multicast address for unsolicited DA Advertisements. If one is detected, and the DA has the right scope, all services which are currently being advertised should be registered with the DA. (unless configured to use a single DA)
Not Done.
must be able to unicast registrations and unregistrations to a DA. Transactions should be made reliable by using retransmission of the request if the reply does not arrive within a timeout interval.
Partially Done.
must be able to detect DAs using a Directory Agent Discovery request issued when the SA starts up. (unless configured to use a single DA)
Partially Done.
must use the IP authentication Header or IP Encapsulating Payload in all Service Location messages, whenever an appropriate IPSec Security Association exists.
Not Done.
must be able to register service information with a DA using US-ASCII character encoding. It must also be able to reply to requests from UAs which use US-ASCII character encoding.
Done.
must reregister with a DA before the Lifetime of registered service information elapses.
Not Done.
should be able to listen to the multicast address of the service it is advertising. The incoming requests should be filtered : if the address specification of the SA is in the previous responders address specification list, the SA should not respond. Otherwise, a response to the multicast query should be unicast to the UA which sent the request.
Not Done.
should be able to listen for a broadcast request and TCP connection requests, to the service location port.
Not Done.
should be able to listen to the service location general multicast address for queries of any type. If the query can be replied to by the service agent, the service agent must do so. It must check first to make sure it is not on the list of the previous responders. It will receive service type requests this way.
Not Done.
may be able to get the address of a local directory agent by way of DHCP.
Not Done.
may accept requests in non-US ASCII character encoding. This is encouraged, especially with UNICODE and UTF-8 encodings.
Not Done.
may register services with a DA in non-US ASCII character encoding. This is encouraged, especially with UNICODE and UTF-8 encodings.
Not Done.
This section show how the programs work. It explains the syntax of the commands and show how the results are given.
The Directory Agent is configured with a file :
./da -h
Usage : ./da [-file
config-file] [-ttl ttl_value]
With this configuration file
SERVICE :DIRECTORY-AGENT ://mousson.enst.fr
CAL,INF
./da -file da.mousson
DA running with pid 21208, ttl 32
URL : SERVICE :DIRECTORY-AGENT ://mousson.enst.fr
Scope : CAL,INF
So far, the service agent is done by a program called register. It uses the file register.dat
It has got 3 lines. The first line is the time to live (in minutes), the second line is the URL and the third line is the attributes.
1440
SERVICE :printer ://ulysse.enst.fr :515
(PAPER COLOR=WHITE),(SCOPE=INF,CAL)
./register
URL : SERVICE :DIRECTORY-AGENT ://mousson.enst.fr
Scope : CAL,INF
Comment : Contacting mousson.enst.fr to register
: Ack got : No
Error
./ua " printer//(& (PAPER COLOR==WHITE) (SCOPE==INF))/ "
Directory Agent found at mousson.enst.fr
URL : SERVICE :DIRECTORY-AGENT ://mousson.enst.fr
Scope : CAL,INF
Comment : Contacting mousson.enst.fr
: error code : No Error
: Number of Replies 1
: SERVICE :printer ://ulysse.enst.fr :515
: Attributes :
(PAPER COLOR=WHITE),(SCOPE=INF,CAL)
./ua " printer//(& (PAPER COLOR=WHITE) (SCOPE=INF))/ "
Directory Agent found at mousson.enst.fr
URL : SERVICE :DIRECTORY-AGENT ://mousson.enst.fr
Scope : CAL,INF
Comment : Contacting mousson.enst.fr
: error code : Protocol Parse Error
: Number of Replies 0
The output could be modified in the versions to be coming.
I started to work on my Linux Box. The main reason of that is that in case of a problem, I wouldn't have damaged anything, and since we have no multicast tunnel where my PC is, I had no possibility to flood other people ! I was also very helpful since it was compiling quicker on my pentium than on the sparc I could use.
After I made it work on my Linux, I quickly tried to make it work on Solaris. One advantage of Linux is that it is POSIX compliant, so I didn't meet too many problems.
The only requirement I have to port my programs is :
This installation of my programs works with the help of a install.sh programs that detects the architecture and sets the good options accordingly.
Anyway, I think that once the above requirements
are done, my programs should work anywere.
One of the most difficult thing to find is a multicast
support. However some machines have the multicast variables (like
IP_MULTICAST_TTL)
in their includes files but do not support multicast in reality.
So, far these are the architectures that have been fully tested :
Here are the architecture that should work : (ie the programs do compile but have not been tested, mostly because of Multicast lack on those machines)
As of Saturday, July 06, 1996
The aim of this section is to help future developers use these functions.
int parse(char *string) ;
The function returns 1 if string is a predicate.
(according to the grammar). The function returns 0 if the string
cannot be considered as a predicate.
int parse_url(char *string) ;
The function returns 1 if string is a URL. (according
to the draft). The function returns 0 if the string cannot be
considered as a URL.
int parse_attr(char *string) ;
The function returns 1 if string is a set of attributes.
The function returns 0 elsewhere.
int check_valid(char *where,char *attributes) ;
The function returns 1 if the attributes correspond to a true value of the where clause.
For example if :
where = (& (PAPER COLOR==WHITE) (UNRESTRICTED) (ROOM==C221))
attributes = (PAPER COLOR=WHITE,BLUE,RED),(ROOM=C221)
check_valid
will reply 0.
where = (& (PAPER COLOR==WHITE) (UNRESTRICTED) (ROOM==C221))
attributes = (PAPER COLOR=WHITE,BLUE,RED),UNRESTRICTED,(ROOM=C221)
check_valid
will reply 1..
int compute(char *buffer, int len, struct Base *DA_Base) ;
It analyses the request received on the network. The request is stored in buffer (size len). The request is processed (SRVRQST, SRVREG, SRVDEREG, ...) and stores the reply in _r (size _rlen). Thoses two variables have to be declared external, and need to be freed after they are used.
The function returns 0 in case of success, a number
greater than 0 in case an error has occured, and -1 if the request
could not be processed. (internal error)
int process_request(char *buffer, int len, struct Base *DA_Base) ;
This function does like compute but ONLY for Service
Requests (SRVRQST).
int Make_Reg_String(char *req, int reqlen, int version, int length, int O,int M, int flags, int char_encoding, int time_to_live, int xid, char language_code[2], int language_dialect, char *url, char *attr) ;
This function makes a network packet in order to
register the specified service. The packet is stored in req (size
reqlen). Req has to be allocated BEFORE Make_Reg_String is called.
int Make_DeReg_String(char *req, int reqlen, int version, int length, int O,int M, int flags, int char_encoding, int time_to_live, int xid, char language_code[2], int language_dialect, char *url, char *attr) ;
This function makes a network packet in order to
deregister the specified service. The packet is stored in req
(size reqlen). Req has to be allocated BEFORE Make_DeReg_String
is called.
int verif_cond(char *data, char *request) ;
This function tests whether
int included_info(char *string, char *token) ;
This function tests whether the information asked is provided by the Service.
The function replies 1 if the information is included.
(0 elsewhere).
int correct_scope_val(char *url, char *da) ;
This function checks whether the SCOPE in the URL is valid.
The function returns 0 if the scope is valid.
int correct_scope(char *request, char *da) ;
This function checks whether the scope of the Requester matches the DA's.
The function returns 1 if the scope of the requester
is included in the DA's one.
void advertise(char *addr, int port, struct Base *Reply, int ttl) ;
The function makes a DA Advertisement frame an emits
it on the network with the ttl given.
struct SLP_Reply *discover(int complete, char *addr, int port, char *request, int ttl);
If complete is 1, discover makes a complete query,
using the convergence mechanism. If complete is different from
1, only the first responder is returned. The query is done for
the string request (for example " DIRECTORY-AGENT :/// ")
with the ttl given, on the multicast address and port given.
int multicast_send_socket(struct sockaddr_in DestAddr, int ttl) ;
The function returns the socket number association
to the address in argument.
int multicast_send (char *addr, int port, char *msg, int sizemsg, int ttl) ;
The function returns the number of bytes sent to
the address. It should be equal to sizemsg.
int multicast_receive_socket(char *destmcast, int port , int ttl) ;
The function returns the socket number associated
to the port and multicast address to listen to.
int multicast_receive(int s, char *msg, int sizemsg, struct in_addr *inaddr, int timeout) ;
The function returns the number of bytes receives.
The function does not listen any longer than the timeout time
given.
int answer_multicast(char *addr, int port, int sockr, struct Base *DA_Base, int ttl) ;
The function receives a multicast packet, processes
the request, and sends back the reply.
int udp_receive_socket(int port) ;
The function returns the socket number associated.
int tcp_receive_socket(int port) ;
The function returns the socket number associated.
void answer_tcp(int sock, struct Base *DA_Base) ;
This function answers a TCP request on the socket
sock.
void answer_udp(int sock, struct Base *DA_Base) ;
This function answers a UDP (non multicast) request
on the socket sock.
void tcp_send(char *req, int reqlen, struct hostent *host, int port) ;
This function send the packet coded by req, of size
reqlen, to the site given by hostent to the TCP port given.
| IETF Draft Service Location Protocol
John Veizades (TGV Inc), Erik Guttman (Sun Microsystems), Charles Perkins (IBM Research) and Scott Kaplan. | ftp ://ds.internic.net/internet-drafts/ draft-ietf-svrloc-protocol-14.txt |
| Internet et Collecticiels - Le Multicast
Philippe Dax, Christine Potier and Christine Vercken, ENST, Paris | http ://www-inf.enst.fr/~dax/conf/multicast/multicast.html |
| Multicast Routing
Cisco Corporation | http ://www-europe.cisco.com/warp/public/614/17.htm |
| The Brain Bone's Connected to the MBONE
Kevin Savetz, Songline Studios Inc. | http://www.gnn.com/gnn/wr/tech/savetz/sept1/index.html |
| The MBONE FAQ
Kevin Hugues | http ://www.best.com/~prince/techinfo/mbone.faq.html |
| MBONE Desktop Applications
Vinay Kumar | http ://www.best.com/~prince/techinfo/mc-soft.html |
| Windows Sockets Network Programming
Bob Quinn and Dave Shute, Addison Wesley Editions | http ://www.sockets.com/wsnp.htm |
| RMP, Reliable Multicast Protocol
NASA | http ://atlantis.ivv.nasa.gov/projects/RMP/RMP.html |
| Lex & Yacc, 2nd Edition
John R. Levine, Tony Mason & Doug Brown, O'Reilly & Associates | ftp ://ftp.uu.net/nutshell/lexyacc/progs.tar.Z |