Thursday, November 20, 2008
How to install MySQL on fedora
- Use
yumto install both mysql command line tool and the server:yum -y install mysql mysql-server - Enable the MySQL service:
/sbin/chkconfig mysqld on - Start the MySQL server:
/sbin/service mysqld start - Set the MySQL root password:
mysqladmin -u root password 'new-password'The quotes around the new password are required.
Thursday, March 13, 2008
On-Demand Multicast Routing Protocol (ODMRP) is:
* A mesh-based, rather than a conventional tree-based, multicast scheme.
* Uses a forwarding group concept (only a subset of nodes forwards the multicast packets via scoped flooding): a set of nodes responsible for forwarding multicast data on shortest paths between any member pairs, to build a forwarding mesh for each multicast group.
* Flooding redundancy among forwarding group helps overcome node displacements and channel fading. Hence, unlike trees, frequent reconfigurations are not required.
* Applies on-demand procedures to dynamically build routes and maintain multicast group membership.
* Well suited for ad hoc wireless networks with mobile hosts where bandwidth is limited, topology changes frequently and power is constrained.
Tree-based Scheme is BAD
Multicast tree structures are fragile and must be readjusted continuously as connectivity changes. Furthermore, typical multicast trees usually require a global routing substructure such as link state or distance vector. The frequent exchange of routing vectors or link state tables, triggered by continuous topology changes, yields excessive channel and processing overhead.
Multicast Route and Membership Maintenance
* Group membership and multicast routes are established and updated by the source on demand.
* While a multicast source has packets to send:
o Multicast source periodically broadcasts a JOIN REQUEST (a member advertising packet) to the entire network. This periodic transmission refreshes the membership information and updates the route.
* When a node receives a non-duplicate JOIN REQUEST, it
o Stores the upstream node ID (i.e., backward learning), and
o Rebroadcasts the packet.
* When the JOIN REQUEST packet reaches a multicast receiver, the receiver
o Creates the source entry in its Member Table, or
o Updates the source entry in its Member Table.
While valid entries exist in the Member Table, JOIN TABLES are broadcasted periodically to the neighbors.
When a node receives a JOIN TABLE:
* It checks if the next node ID of one of the entries matches its own ID.
* If it does, the node realizes that it is on the path to the source and thus is part of the forwarding group.
* It then sets the FG Flag and broadcasts its own JOIN TABLE built upon matched entries.
* The JOIN TABLE is thus propagated by each forwarding group member until it reaches the multicast source via the shortest path. This process constructs (or updates) the routes from sources to receivers and builds a mesh of nodes, the forwarding group.
A multicast receiver can also be a forwarding group node if it is on the path between a multicast source and another receiver.
Example
Nodes S1 and S2 are multicast sources.
Nodes R1, R2, and R3 are multicast receivers.
Nodes R2 and R3 send their JOIN TABLES to both S1 and S2 via I2.
Node R1 sends its JOIN TABLE to S1 via I1 and to S2 via I2.
1. When receivers send their JOIN TABLES to next hop nodes, an intermediate node
2. I1 sets the FG Flag and builds its own JOIN TABLE since there is a next node ID entry in the JOIN TABLE received from R1 that matches its ID.
Note that the JOIN TABLE built by I1 has an entry for sender S1 but not for S2 because the next node ID for S2 in the received JOIN TABLE is not I1.
3. In the meantime, node I2 sets the FG Flag, constructs its own JOIN TABLE and sends it to its neighbors.
4. Note that even though I2 receives three JOIN TABLES from the receivers, it broadcasts the JOIN TABLE only once because the second and third table arrivals carry no new source information.
*Channel overhead is thus reduced dramatically in cases where numerous multicast receivers share the same links to the source.
Data Forwarding
After the group establishment and route construction process, a multicast source can transmit packets to receivers via selected routes and forwarding groups.
Periodic control packets are sent only when outgoing data packets are still present. When receiving a multicast data packet, a node forwards it only if
* It is not a duplicate and,
* The setting of the FG Flag for the multicast group has not expired. This procedure minimizes traffic overhead and prevents sending packets through stale routes.
Soft State
In ODMRP, no explicit control packets need to be sent to join or leave the group.
If a multicast source wants to leave the group, it simply stops sending JOIN REQUEST packets since it does not have any multicast data to send to the group.
If a receiver no longer wants to receive from a particular multicast group,
* It removes the corresponding entries from its Member Table and,
* It does not transmit the JOIN TABLE for that group.
Nodes in the forwarding group are demoted to non-forwarding nodes if not refreshed (no JOIN TABLES received) before they timeout.
Data Structures
Network hosts running ODMRP are required to maintain the following data structures.
* Member Table:
o Each multicast receiver stores the source information in the Member Table.
o For each multicast group the node is participating in, the source ID and the time when the last JOIN REQUEST is received from the source is recorded.
o If no JOIN REQUEST is received from a source within the refresh period, that entry is removed from the Member Table.
* Routing Table:
o A Routing Table is created on demand and is maintained by each node.
o An entry is inserted or updated when a non-duplicate JOIN REQUEST is received.
o The node stores the destination (i.e., the source of the JOIN REQUEST) and the next hop to the destination (i.e., the last node that propagated the JOIN REQUEST).
o The Routing Table provides the next hop information when transmitting Join Tables.
* Forwarding Group Table:
o When a node is a forwarding group node of the multicast group, it maintains the group information in the Forwarding Group Table.
o The multicast group ID and the time when the node was last refreshed is recorded.
* Message Cache:
o The Message Cache is maintained by each node to detect duplicates.
o When a node receives a new JOIN REQUEST or data, it stores the source ID and the sequence number of the packet.
o *Note that entries in the Message Cache need not be maintained permanently.
o *Schemes such as LRU (Least Recently Used) or FIFO (First In First Out) can be employed to expire and remove old entries and prevent the size of the Message Cache to be extensive.
Unicast Capability
One of the major strengths of ODMRP is its unicast routing capability. Not only ODMRP can work with any unicast routing protocol, it can function as both multicast and unicast. Thus, ODMRP can run without any underlying unicast protocol.
Advantages:
* Low channel and storage overhead
* Usage of up-to-date and shortest routes
* Robustness to host mobility
* Maintenance and exploitation of multiple redundant paths
* Scalability to a large number of nodes
* A mesh-based, rather than a conventional tree-based, multicast scheme.
* Uses a forwarding group concept (only a subset of nodes forwards the multicast packets via scoped flooding): a set of nodes responsible for forwarding multicast data on shortest paths between any member pairs, to build a forwarding mesh for each multicast group.
* Flooding redundancy among forwarding group helps overcome node displacements and channel fading. Hence, unlike trees, frequent reconfigurations are not required.
* Applies on-demand procedures to dynamically build routes and maintain multicast group membership.
* Well suited for ad hoc wireless networks with mobile hosts where bandwidth is limited, topology changes frequently and power is constrained.
Tree-based Scheme is BAD
Multicast tree structures are fragile and must be readjusted continuously as connectivity changes. Furthermore, typical multicast trees usually require a global routing substructure such as link state or distance vector. The frequent exchange of routing vectors or link state tables, triggered by continuous topology changes, yields excessive channel and processing overhead.
Multicast Route and Membership Maintenance
* Group membership and multicast routes are established and updated by the source on demand.
* While a multicast source has packets to send:
o Multicast source periodically broadcasts a JOIN REQUEST (a member advertising packet) to the entire network. This periodic transmission refreshes the membership information and updates the route.
* When a node receives a non-duplicate JOIN REQUEST, it
o Stores the upstream node ID (i.e., backward learning), and
o Rebroadcasts the packet.
* When the JOIN REQUEST packet reaches a multicast receiver, the receiver
o Creates the source entry in its Member Table, or
o Updates the source entry in its Member Table.
While valid entries exist in the Member Table, JOIN TABLES are broadcasted periodically to the neighbors.
When a node receives a JOIN TABLE:
* It checks if the next node ID of one of the entries matches its own ID.
* If it does, the node realizes that it is on the path to the source and thus is part of the forwarding group.
* It then sets the FG Flag and broadcasts its own JOIN TABLE built upon matched entries.
* The JOIN TABLE is thus propagated by each forwarding group member until it reaches the multicast source via the shortest path. This process constructs (or updates) the routes from sources to receivers and builds a mesh of nodes, the forwarding group.
A multicast receiver can also be a forwarding group node if it is on the path between a multicast source and another receiver.
Example
Nodes S1 and S2 are multicast sources.
Nodes R1, R2, and R3 are multicast receivers.
Nodes R2 and R3 send their JOIN TABLES to both S1 and S2 via I2.
Node R1 sends its JOIN TABLE to S1 via I1 and to S2 via I2.
1. When receivers send their JOIN TABLES to next hop nodes, an intermediate node
2. I1 sets the FG Flag and builds its own JOIN TABLE since there is a next node ID entry in the JOIN TABLE received from R1 that matches its ID.
Note that the JOIN TABLE built by I1 has an entry for sender S1 but not for S2 because the next node ID for S2 in the received JOIN TABLE is not I1.
3. In the meantime, node I2 sets the FG Flag, constructs its own JOIN TABLE and sends it to its neighbors.
4. Note that even though I2 receives three JOIN TABLES from the receivers, it broadcasts the JOIN TABLE only once because the second and third table arrivals carry no new source information.
*Channel overhead is thus reduced dramatically in cases where numerous multicast receivers share the same links to the source.
Data Forwarding
After the group establishment and route construction process, a multicast source can transmit packets to receivers via selected routes and forwarding groups.
Periodic control packets are sent only when outgoing data packets are still present. When receiving a multicast data packet, a node forwards it only if
* It is not a duplicate and,
* The setting of the FG Flag for the multicast group has not expired. This procedure minimizes traffic overhead and prevents sending packets through stale routes.
Soft State
In ODMRP, no explicit control packets need to be sent to join or leave the group.
If a multicast source wants to leave the group, it simply stops sending JOIN REQUEST packets since it does not have any multicast data to send to the group.
If a receiver no longer wants to receive from a particular multicast group,
* It removes the corresponding entries from its Member Table and,
* It does not transmit the JOIN TABLE for that group.
Nodes in the forwarding group are demoted to non-forwarding nodes if not refreshed (no JOIN TABLES received) before they timeout.
Data Structures
Network hosts running ODMRP are required to maintain the following data structures.
* Member Table:
o Each multicast receiver stores the source information in the Member Table.
o For each multicast group the node is participating in, the source ID and the time when the last JOIN REQUEST is received from the source is recorded.
o If no JOIN REQUEST is received from a source within the refresh period, that entry is removed from the Member Table.
* Routing Table:
o A Routing Table is created on demand and is maintained by each node.
o An entry is inserted or updated when a non-duplicate JOIN REQUEST is received.
o The node stores the destination (i.e., the source of the JOIN REQUEST) and the next hop to the destination (i.e., the last node that propagated the JOIN REQUEST).
o The Routing Table provides the next hop information when transmitting Join Tables.
* Forwarding Group Table:
o When a node is a forwarding group node of the multicast group, it maintains the group information in the Forwarding Group Table.
o The multicast group ID and the time when the node was last refreshed is recorded.
* Message Cache:
o The Message Cache is maintained by each node to detect duplicates.
o When a node receives a new JOIN REQUEST or data, it stores the source ID and the sequence number of the packet.
o *Note that entries in the Message Cache need not be maintained permanently.
o *Schemes such as LRU (Least Recently Used) or FIFO (First In First Out) can be employed to expire and remove old entries and prevent the size of the Message Cache to be extensive.
Unicast Capability
One of the major strengths of ODMRP is its unicast routing capability. Not only ODMRP can work with any unicast routing protocol, it can function as both multicast and unicast. Thus, ODMRP can run without any underlying unicast protocol.
Advantages:
* Low channel and storage overhead
* Usage of up-to-date and shortest routes
* Robustness to host mobility
* Maintenance and exploitation of multiple redundant paths
* Scalability to a large number of nodes
Thursday, January 10, 2008
Surat Kepada Kawan Di Suatu Petang
Kawan, perjumpaan kita, barangkali, sebuah kebetulan yang tak pernah diniatkan. Tapi, begitulah hidup sering mengajarkan: Kerap ada perihal misterius yang mencemooh ikhtiar untuk menjabarkan, setiap kali kita berlagak rasional. Maka, Tuhan pun menautkan kita dalam cara yang amat sahaja, lugu, tak kebanyakan tingkah. Hingga pada suatu ketika.Kau bertandang sambil menyuguhkan sepotong paras khas pemikir letih. Kau tiba-tiba ingin berhenti—atau setidaknya membikin interupsi—atas hidup yang bergerak menuju renta. Kau masih memanjakan kecewa dengan koar yang, sejujurnya, tak seluruhnya kumengerti benar. Tapi kau meneruskan muntab, setengah mengutuk. Tentang perselisihan, silap, khilaf, kalap, onar. Tentang dosa, dan salah.
Kawan, saya pun tidak mafhum mengapa perihal-perihal banal seringkali kekal dan kental bersahabat dengan kita. Sekurangnya, karena kita tahu, di semua jazirah para nabi pernah diutus dan firman sempat bergema. Adakah dengan begitu para aulia gagal mewariskan pekerti? Adakah dengan begitu kita boleh bertanya-tanya, apa gunanya wahyu bagi hidup manusia?
Saya tiba-tiba teringat pada cerita lama Ibrahim bin Adham yang hidup di abad ke-8. Seorang alim rendah hati yang tak pernah merasa lebih taat dan lebih dekat dengan Tuhan. Ia mengumpul kayu bakar dan pergi berladang. Penghasilannya, diderma pada orang yang tertimpa malang. Syahdan, ia menjenguk Ka’bah di sebuah malam ketika gemuruh guntur dan hujan deras datang berbarengan. Usai tawaf panjang ia mengangkat tangan, mengajukan permohonan. "Tuhan, jaga aku dari berbuat dosa terhadap-Mu."
Konon, sebersit suara tiba-tiba membisik. "Ibrahim, bila Kupenuhi doamu dan doa semua hamba-Ku yang serupa denganmu, pada siapa gerangan Kulimpah belas-Ku, kemaafan-Ku, ampunan-Ku?"
Kawan, entah apa yang melintasi benakmu ketika kututurkan cerita itu. Kisah sufi itu, bagi banyak orang terasa amat menggetarkan. Bukan karena bersitan suara yang tiba-tiba saja membisik telinga Ibrahim. Melainkan betapa Tuhan berkenan menerima kenyataan manusia, apa adanya. Yang tak seluruhnya mampu luruh dari silap dan khilaf yang mungkin. Kita dituntun ke pucuk kesadaran, betapa Tuhan, adalah rahman. Adalah rahim.
Saya pun kadang lupa akan hal itu. Yang kerap memaksa manusia lain tersungkur dalam kemustahilan sebuah itikad: menjadi si suci yang bebas dosa 24 jam sehari. Padahal kita gemar membolak-balik kitab-kitab sejarah seraya mendapati: Manusia yang memaksa manusia lainnya tak pernah berbuat salah justru karam dalam penindasan maha hebat. Ada indoktrinasi bertalu-talu, dan cemeti yang siap merobek kulit di setiap salah ucap. Kau tiba-tiba mendesiskan nama Pol Pot, Gulag, Hitler, Aurangzeb, dan entah siapa lagi.
Tuntutan kesempurnaan yang serba bulat itu justru tiba-tiba dihadapkan dengan realitas yang sama sekali lain: penghinadinaan atas harkat manusia. Sebuah degradasi kontras tentang nilai-nilai. Dan karenanya, terasa sangat tak pantas.
Salah, khilaf, dosa. Pada akhirnya kita mengerti akan batas. Mengerti akan kelemahan. Mengerti akan ketidaksempurnaan. Mengerti akan pentingnya rendah hati. Dan pongah serta merta tumpas, tersungkur di ambang haribaan-Nya dengan jantung yang hampir lepas. Paras dan Laku-Nya yang sempurna. Kita selamanya tak akan menjadi Dia. Lantaran itulah firman bergema. Lantaran Tuhan sajalah yang paling mengerti batas ciptaan-Nya.
Kawan,
salah, khilaf, dosa. Pada akhirnya kita belajar berendah hati, berikhtiar tulus, menyisipkan itikad ikhlas ke ruas hati. Manusia yang sadar akan batas, manusia yang sadar akan lemah diri. Ketidaksempurnaan adalah monopoli kita, dan Tuhan tak pernah kapok menyuguhkan pengampunan. Maka, kita menemukan sebuah alasan untuk selalu menghaturkan maaf, atas segala ketidakbecusan, kebanalan, khilaf, salah, dosa yang bertalu-talu pernah kita perbuat. Sebagaimana kini kita menemukan alasan untuk tak lagi kikir memberi kemaafan dan pengampunan bagi semua.
Kawan, selamat berlebaran di tahun ke-1428. Maafkan saya, mohon maafkan khilaf saya.
Subscribe to:
Posts (Atom)
