Showing posts with label Networking. Show all posts
Showing posts with label Networking. Show all posts

Wednesday, 2 October 2019

WTA Architecture


Browsing the web using the WML browser is only one application for a handheld device user. Say a user still wants to make phone calls and access all the features of the mobile phone network as with a traditional mobile phone. This is where the wireless telephony application (WTA), the WTA user agent (as shown in Figure), and the wireless telephony application interface WTAI come in. WTA is a collection of telephony specific extensions for call and feature control mechanisms, merging data networks and voice networks.
The WTA framework integrates advanced telephony services using a consistent user interface (e.g., the WML browser) and allows network operators to increase accessibility for various special services in their network. A network operator can reach more end-devices using WTA because this is integrated in the wireless application environment (WAE) which handles device-specific characteristics and environments. WTA should enable third-party developers as well as network operators to create network-independent content that accesses the basic features of the bearer network. However, most of the WTA functionality is reserved for the network operators for security and stability reasons.
WTA extends the basic WAE application model in several ways:
 Content push: A WTA origin server can push content, i.e., WML decks or WMLScript, to the client. A push can take place without prior client request. The content can enable, e.g., the client to handle new network events that were unknown before. Access to telephony functions: The wireless telephony application interface (WTAI, WAP Forum, 2000m) provides many functions to handle telephony events (call accept, call setup, change of phone book entries etc.).
 Repository for event handlers: The repository represents a persistent storage on the client for content required to offer WTA services. Content are either channels or resources. Examples for resources are WML decks, WMLScript objects, or WBMP pictures. Resources are loaded using WSP or are pre-installed. A channel comprises references to resources and is associated with a lifetime. Within this lifetime, it is guaranteed that all resources the channel points to are locally available in the repository. The motivation behind the repository is the necessity to react very quickly for time-critical events (e.g., call accept). It would take too long to load content from a server for this purpose.

  Security model: Mandatory for WTA is a security model as many frauds happen with wrong phone numbers or faked services. WTA allows the client to only connect to trustworthy gateways, which then have to check if the servers providing content are authorized to send this content to the client. Obviously, it is not easy to define trustworthy in this context. In the beginning, the network operator‟s gateway may be the only trusted gateway and the network operator may decide which servers are allowed to provide content. Figure 10.30 gives an overview of the WTA logical architecture.
The components shown are not all mandatory in this architecture; however, firewalls or other origin servers may be useful. A minimal configuration could be a single server from the network operator serving all clients. The client is connected via a mobile network with a WTA server, other telephone networks (e.g., fixed PSTN), and a WAP gateway. A WML user agent running on the client or on other user agents is not shown here.
The client may have voice and data connections over the mobile network. Other origin servers within the trusted domain may be connected via the WAP gateway. A firewall is useful to connect third-party origin servers outside the trusted domain. One difference between WTA servers and other servers besides security is the tighter control of QoS. A network operator knows (more or less precisely) the latency, reliability, and capacity of its mobile network and can have more control over the behavior of the services. Other servers, probably located in the internet, may not be able to give as good QoS guarantees as the network operator.
Similarly, the WTA user agent has a very rigid and real-time context management for browsing the web compared to the standard WML user agent. Figure shows an exemplary interaction between a WTA client, a WTA gateway, a WTA server, the mobile network (with probably many more servers) and a voice box server. Someone might leave a message on a voice box server as indicated. Without WAP, the network operator then typically generates an SMS indicating the new message on the voice box via a little symbol on the mobile phone. However, it is typically not indicated who left a message, what messages are stored etc. Users have to call the voice box to check and cannot choose a particular message. In a WAP scenario, the voice box can induce the WTA server to generate new content for pushing to the client. An example could be a WML deck containing a list of callers plus length and priority of the calls. The server does not push this deck immediately to the client, but sends a push message containing a single
URL to the client. A short note, e.g., ―5 new calls are stored", could accompany the push message. The WTA gateway translates the push URL into a service indication and codes it into a more compact binary format. The WTA user agent then indicates that new messages are stored. If the user wants to listen to the stored messages, he or she can request a list of the messages.
This is done with the help of the URL. A WSP get requests the content the URL points to. The gateway translates this WSP get into an HTTP get and the server responds with the prepared list of callers.
After displaying the content, the user can select a voice message from the list. Each voice message in this example has an associated URL, which can request a certain WML card from the server. The purpose of this card is to prepare the client for an incoming call. As soon as the client receives the card, it waits for the incoming call. The call is then automatically accepted. The WTA server also signals the voice box system to set up a (traditional) voice connection to play the selected voice message. Setting up the call and accepting the call is shown using dashed lines, as these are standard interactions from the mobile phone network, which are not controlled by WAP.

Wireless Application Environment


The main idea behind the wireless application environment (WAE) is to create a general-purpose application environment based mainly on existing technologies and philosophies of the world wide web. This environment should allow service providers, software manufacturers, or hardware vendors to integrate their applications so they can reach a wide variety of different wireless platforms in an efficient way. However, WAE does not dictate or assume any specific man-machine-interface model, but allows for a variety of devices, each with its own capabilities and probably vendor-specific extras (i.e., each vendor can have its own look and feel). WAE has already integrated the following technologies and adapted them for use in a wireless environment with low power handheld devices.
HTML, JavaScript, and the handheld device markup language HDML form the basis of the wireless markup language (WML) and the scripting language WML script. The exchange formats for business cards and phone books vCard and for calendars vCalendar have been included. URLs from the web can be used. A wide range of mobile telecommunication technologies have been adopted and integrated into the wireless telephony application (WTA).
Besides relying on mature and established technology, WAE focuses on devices with very limited capabilities, narrow-band environments, and special security and access control features. The first phase of the WAE specification developed a whole application suite, especially for wireless clients as presented in the following sections. Future developments for the WAE will include extensions for more content formats, integration of further existing or emerging technologies, more server-side aspects, and the integration of intelligent telephone networks.
One global goal of the WAE is to minimize over-the-air traffic and resource consumption on the handheld device. This goal is also reflected in the logical model underlying WAE (Figure 10.29) showing some more detail than the general overview in Figure 10.10. WAE adopts a model that closely follows the www model, but assumes additional gateways that can enhance transmission efficiency.
A client issues an encoded request for an operation on a remote server. Encoding is necessary to minimize data sent over the air and to save resources on the handheld device as explained together with the languages WML and WMLscript. Decoders in a gateway now translate this encoded request into a standard request as understood by the origin servers. This could be a request to get a web page to set up a call. The gateway transfers this request to the appropriate origin server as if it came from a standard client. Origin servers could be standard web servers running HTTP and generating content using scripts, providing pages using a database, or applying any other (proprietary) technology. WAE does not specify any standard content generator or server, but assumes that the majority will follow the standard technology used in today‘s www.
The origin servers will respond to the request. The gateway now encodes the response and its content (if there is any) and transfers the encoded response with the content to the client. The WAE logical model not only includes this standard request/response scheme, but it also includes push services. Then an origin server pushes content to the gateway. The gateway encodes the pushed content and transmits the encoded push content to the client.
Several user agents can reside within a client. User agents include such items as: browsers, phonebooks, message editors etc. WAE does not specify the number of user agents or their functionality, but assumes a basic WML user agent that supports WML, WML script, or both (i.e., a ‗WML browser‘). Further domain specific user agents with varying architectures can be implemented. Again, this is left to vendors. However, one more user agent has been specified with its fundamental services, the WTA user agent. This user agent handles access to, and interaction with, mobile telephone features (such as call control). As over time many vendor dependent user agents may develop, the standard defines a user agent profile (UAProf), which describes the capabilities of a user agent. Capabilities may be related to hardware or software.
Examples are: display size, operating system, browser version, processor, memory size, audio/video codec, or supported network types. The basic languages WML and WML Script , and the WTA will be described in the following three sections.

Wireless session protocol (WSP)

The wireless session protocol (WSP) has been designed to operate on top of the datagram service WDP or the transaction service WTP (WAP Forum, 2000e). For both types, security can be inserted using the WTLS security layer if required. WSP provides a shared state between a client and a server to optimize content transfer. HTTP, a protocol WSP tries to replace within the wireless domain, is stateless, which already causes many problems in fixed networks. Many web content providers therefore use cookies to store some state on a client machine, which is not an elegant solution. State is needed in web browsing, for example, to resume browsing in exactly the same context in which browsing has been suspended. This is an important feature for clients and servers. Client users can continue to work where they left the browser or when the network was interrupted, or users can get their customized environment every time they start the browser. Content providers can customize their pages to clients‘ needs and do not have to retransmit the same pages over and over again. WSP offers the following general features needed for content exchange between cooperating clients and servers:
● Session management: WSP introduces sessions that can be established from a client to a server and may be long lived. Sessions can also be released in an orderly manner. The capabilities of suspending and resuming a session are important to mobile applications. Assume a mobile device is being switched off – it would be useful for a user to be able to continue operation at exactly the point where the device was switched off. Session lifetime is independent of transport connection lifetime or continuous operation of a bearer network.
· Capability negotiation: Clients and servers can agree upon a common level of protocol functionality during session establishment. Example parameters to negotiate are maximum client SDU size, maximum outstanding requests, protocol options, and server SDU size.
c) Content encoding: WSP also defines the efficient binary encoding for the content it transfers. WSP offers content typing and composite objects, as explained for web browsing. While WSP is a general-purpose session protocol, WAP has specified the wireless session protocol/browsing (WSP/B) which comprises protocols and services most suited for browsing-type applications. In addition to the general features of WSP, WSP/B offers the following features adapted to web browsing:
d) HTTP/1.1 functionality: WSP/B supports the functions HTTP/1.1 offers, such as extensible request/reply methods, composite objects, and content type negotiation. WSP/B is a binary form of HTTP/1.1. HTTP/1.1 content headers are used to define content type, character set encoding, languages etc., but binary encodings are defined for well-known headers to reduce protocol overheads.
e) Exchange of session headers: Client and server can exchange request/reply headers that remain constant over the lifetime of the session. These headers may include content types, character sets, languages, device capabilities, and other static parameters. WSP/B will not interpret header information
but passes all headers directly to service users.
f)  Push and pull data transfer: Pulling data from a server is the traditional mechanism of the web. This is also supported by WSP/B using the request/response mechanism from HTTP/1.1. Additionally, WSP/B supports three push mechanisms for data transfer: a confirmed data push within an existing session context, a non-confirmed data push within an existing session context, and a non-confirmed data push without an existing session context.
g)                 Asynchronous requests: Optionally, WSP/B supports a client that can send multiple requests to a server simultaneously. This improves efficiency for the requests and replies can now be coalesced into fewer messages. Latency is also improved, as each result can be sent to the client as soon as it is available.
As already mentioned, WSP/B can run over the transaction service WTP or the datagram service WDP. The following shows several protocol sequences typical for session management, method invocation, and push services.

Wireless transaction protocol (WTP)

The wireless transaction protocol (WTP) is on top of either WDP or, if security is required, WTLS (WAP Forum, 2000d). WTP has been designed to run on very thin clients, such as mobile phones. WTP offers several advantages to higher layers, including an improved reliability over datagram services, improved efficiency over connection-oriented services, and support for transaction-oriented services such as web browsing. In this context, a transaction is defined as a request with its response, e.g. for a web page. WTP offers many features to the higher layers. The basis is formed from three classes of transaction service as explained in the following paragraphs. Class 0 provides unreliable message transfer without any result message. Classes 1 and 2 provide reliable message transfer, class 1 without, class 2 with, exactly one reliable result message (the typical request/response case).
WTP achieves reliability using duplicate removal, retransmission, acknowledgements and unique transaction identifiers. No WTP-class requires any connection set-up or tear-down phase. This avoids unnecessary overhead on the communication link. WTP allows for asynchronous transactions, abort of transactions, concatenation of messages, and can report success or failure of reliable messages (e.g., a server cannot handle the request). To be consistent with the specification, in the following the term initiator is used for a WTP entity initiating a transaction (aka client), and the term responder for the WTP entity responding to a transaction (aka server). The three service primitives offered by WTP are TR-Invoke to initiate a new transaction, TR-Result to send back the result of a previously initiated transaction, and TR-Abort to abort an existing transaction. The PDUs exchanged between two WTP entities for normal transactions are the invoke PDU, ack PDU, and result PDU.
A special feature of WTP is its ability to provide a user acknowledgement or, alternatively, an automatic acknowledgement by the WTP entity. If user acknowledgement is required, a WTP user has to confirm every message received by a WTP entity. A user acknowledgement provides a stronger version of a confirmed service because it guarantees that the response comes from the user of the WTP and not the WTP entity itself. WTP class 0 Class 0 offers an unreliable transaction service without a result message. The transaction is stateless and cannot be aborted. The service is requested with the TR-Invoke.req primitive as shown in Figure 10.14. Parameters are the source address (SA), source port (SP), destination address (DA), destination port (DP) as already explained in section 10.3.2. Additionally, with the A flag the user of this service can determine, if the responder WTP entity should generate an acknowledgement or if a user acknowledgement should be used. The WTP layer will transmit the user data (UD) transparently to its destination. The class type C indicates here class 0. Finally, the transaction handle H provides a simple index to uniquely identify the transaction and is an alias for the tuple (SA, SP, DA, DP), i.e., a socket pair, with only local significance.
The WTP entity at the initiator sends an invoke PDU which the responder receives. The WTP entity at the responder then generates a TR-Invoke.ind primitive with the same parameters as on the initiators side, except for which is now the local handle for the transaction on the responders side. In this class, the responder does not acknowledge the message and the initiator does not perform any retransmission. Although this resembles a simple datagram service, it is recommended to use WDP if only a datagram service is required. WTP class 0 augments the transaction service with a simple datagram like service for occasional use by higher layers.
WTP class 1 Class 1 offers a reliable transaction service but without a result message. Again, the initiator sends an invoke PDU after a TR-Invoke.req from a higher layer.
This time, class equals „1, and no user acknowledgement has been selected as shown in Figure 10.15. The responder signals the incoming invoke PDU via the TR-Invoke.ind primitive to the higher layer and acknowledges automatically without user intervention. The specification also allows the user on the responders side to acknowledge, but this acknowledgement is not required. For the initiator the transaction ends with the reception of the acknowledgement. The responder keeps the transaction state for some time to be able to retransmit the acknowledgement if it receives the same invoke PDU again indicating a loss of the acknowledgement.
If a user of the WTP class 1 service on the initiators side requests a user acknowledgement on the responders side, the sequence diagram looks like Figure. Now the WTP entity on the responders side does not send an acknowledgement automatically, but waits for the TR-Invoke.res service primitive from the user. This service primitive must have the appropriate local handle H for identification of the right transaction. The WTP entity can now send the ack PDU. Typical uses for this transaction class are reliable push services.
WTP class 2 Finally, class 2 transaction service provides the classic reliable request/response transaction known from many client/server scenarios. Depending on user requirements, many different scenarios are possible for initiator/responder interaction. Three examples are presented below. Figure shows the basic transaction of class 2 without-user acknowledgement. Here, a user on the initiators side requests the service and the WTP entity sends the invoke PDU to the responder. The WTP entity on the responders side indicates the request with the TR-Invoke.ind primitive to a user. The responder now waits for the processing of the request, the user on the responders side can finally give the result UD* to the WTP entity on the responder side using TR-Result.req. The result PDU can now be sent back to the initiator, which implicitly acknowledges the invoke PDU. The initiator can indicate the successful transmission of the invoke message and the result with the two service primitives TR-Invoke.cnf and TR-Result.ind. A user may respond to this result with TR-Result.res. An acknowledgement PDU is then generated which finally triggers the TR-Result.cnf primitive on the responder‟s side. This example clearly shows the combination of two reliable services (TR-Invoke and TR-Result) with an efficient data transmission/acknowledgement.
An even more reliable service can be provided by user acknowledgement as explained above. The time-sequence diagram looks different (see Figure 10.18). The user on the responder‘s side now explicitly responds to the Invoke PDU using the TR-Invoke.res primitive, which triggers the TR-Invoke.cnf on the initiator‘s side via an ack PDU. The transmission of the result is also a confirmed service, as indicated by the next four service primitives. This service will likely be the most common in standard request/response scenarios as, e.g., distributed computing.
If the calculation of the result takes some time, the responder can put the initiator on ―hold on‖ to prevent a retransmission of the invoke PDU as the initiator might assume packet loss if no result is sent back within a certain timeframe. This is shown in the Figure.
After a time-out, the responder automatically generates an acknowledgement for the Invoke PDU. This shows the initiator that the responder is still alive and currently busy processing the request. WTP provides many more features not explained here, such as concatenation and separation of messages, asynchronous transactions with up to 215 transactions outstanding, i.e., requested but without result up to now, and segmentation/ reassembly of messages.

Wireless Datagram Protocol (WDP)


The Wireless Datagram Protocol (WDP) operates on top of many different bearer services capable of carrying data. At the T-SAP WDP offers a consistent datagram transport service independent of the underlying bearer. To offer this consistent service, the adaptation needed in the transport layer can differ depending on the services of the bearer. The closer the bearer service is to IP, the smaller the adaptation can be. If the bearer already offers IP services, UDP is used as WDP. WDP offers more or less the same services as UDP.WDP offers source and destination port numbers used for multiplexing and demultiplexing of data respectively. The service primitive to send a datagram is TDUnitdata.req with the destination address (DA), destination port (DP), Source address (SA), source port (SP), and user data (UD) as mandatory parameters (see Figure 10.11). Destination and source address are unique addresses for the receiver and sender of the user data. These could be MSISDNs (i.e., a telephone number), IP addresses, or any other unique identifiers. The T-DUnitdata.ind service primitive indicates the reception of data. Here destination address and port are only optional parameters.
If a higher layer requests a service the WDP cannot fulfill, this error is indicated with the T-DError.ind service primitive as shown in Figure 10.11. An error code (EC) is returned indicating the reason for the error to the higher layer. WDP is not allowed to use this primitive to indicate problems with the bearer service. It is only allowed to use the primitive to indicate local problems, such as a user data size that is too large. If any errors happen when WDP datagram‘s are sent from one WDP entity to another (e.g. the destination is unreachable, no application is listening to the specified destination port etc.), the wireless control message protocol (WCMP) provides error handling mechanisms for WDP and should therefore be implemented. WCMP contains control messages that resemble the internet control message protocol messages and can also be used for diagnostic and informational purposes.
WCMP can be used by WDP nodes and gateways to report errors. However, WCMP error messages must not be sent as response to other WCMP error messages. In IP-based networks, ICMP will be used as WCMP (e.g., CDPD, GPRS). Typical WCMP messages are destination unreachable (route, port, address unreachable), parameter problem (errors in the packet header), message too big, reassembly failure, or echo request/reply. An additional
WDP management entity supports WDP and provides information about changes in the environment, which may influence the correct operation of WDP. Important information is the current configuration of the device, currently available bearer services, processing and memory resources etc. Design and implementation of this management component is considered vendor-specific and is outside the scope of WAP.
If the bearer already offers IP transmission, WDP (i.e., UDP in this case) relies on the segmentation (called fragmentation in the IP context) and reassembly capabilities of the IP layer as specified in (Postal, 1981a). Otherwise, WDP has to include these capabilities, which is, e.g., necessary for the GSM SMS. The WAP specification provides many more adaptations to almost all bearer services currently available or planned for the future (WAP Forum, 2000q), (WAP Forum, 2000b).

Wireless Transport Layer Security (WTLS)

If requested by an application, a security service, the wireless transport layer security (WTLS), can be integrated into the WAP architecture on top of WDP as specified in (WAP Forum, 2000c). WTLS can provide different levels of security (for privacy, data integrity, and authentication) and has been optimized for low bandwidth, high-delay bearer networks. WTLS takes into account the low processing power and very limited memory capacity of the mobile devices for cryptographic algorithms. WTLS supports datagram and connection-oriented transport layer protocols. New compared to, e.g. GSM, is the security relation between two peers and not only between the mobile device and the base station . WTLS took over many features and mechanisms from TLS (formerly SSL, secure sockets layer, but it has an optimized handshaking between the peers.
Before data can be exchanged via WTLS, a secure session has to be established. This session establishment consists of several steps: Figure illustrates the sequence of service primitives needed for a so-called ‗full handshake‘ (several optimizations are possible).
The originator and the peer of the secure session can both interrupt session establishment any time, e.g., if the parameters proposed are not acceptable.
The first step is to initiate the session with the SEC-Create primitive. Parameters are source address (SA), source port (SP) of the originator, destination address (DA), destination port (DP) of the peer. The originator proposes a key exchange suite (KES) (e.g., RSA, DH, ECC, a cipher suite (CS) (e.g., DES, IDEA, and a compression method (CM) (currently not further specified). The peer answers with parameters for the sequence number mode (SNM), the key refresh cycle (KR) (i.e., how often keys are refreshed within this secure session), the session identifier (SID) (which is unique with each peer), and the selected key exchange suite (KES‘), cipher suite (CS‘), compression method (CM‘). The peer also issues a SEC-Exchange primitive. This indicates that the peer wishes to perform public-key authentication with the client, i.e., the peer requests a client certificate (CC) from the originator.
The first step of the secure session creation, the negotiation of the security parameters and suites, is indicated on the originator‘s side, followed by the request for a certificate. The originator answers with its certificate and issues a SEC-Commit.req primitive. This primitive indicates that the handshake is completed for the originator‘s side and that the originator now wants to switch into the newly negotiated connection state. The certificate is delivered to the peer side and the SEC-Commit is indicated. The WTLS layer of the peer sends back a confirmation to the originator. This concludes the full handshake for secure session setup.
After setting up a secure connection between two peers, user data can be exchanged. This is done using the simple SEC-Unit data primitive as shown in Figure 10.13. SEC-Unit data has exactly the same function as T-D Unit data on the WDP layer, namely it transfers a datagram between a sender and a receiver. This data transfer is still unreliable, but is now secure. This shows that WTLS can be easily plugged into the protocol stack on top of WDP. The higher layers simply use SEC-Unit data instead of T-D Unit data. The parameters are the same here: source address (SA), source port (SP), destination address (DA), destination port (DP), and user data (UD).
This section will not discuss the security-related features of WTLS or the pros and cons of different encryption algorithms. The reader is referred to the specification and excellent cryptography literature. Although WTLS allows for different encryption mechanisms with different key lengths, it is quite clear that due to computing power on the handheld devices the encryption provided cannot be very strong. If applications require stronger security, it is up to an application or a user to apply stronger encryption on top of the whole protocol stack and use WTLS as a basic security level only. Many programs are available for this purpose. It is important to note that the security association in WTLS exists between the mobile WAP-enabled devices and a WAP server or WAP gateway only. If an application accesses another server via the gateway, additional mechanisms are needed for end-to-end security. If for example a user accesses his or her bank account using WAP, the WTLS security association typically ends at the
WAP gateway inside the network operator‘s domain. The bank and user will want to apply additional security mechanisms in this scenario.
Future work in the WTLS layer comprises consistent support for application level security (e.g. digital signatures) and different implementation classes with different capabilities to select from.1`

Friday, 2 August 2019

Set different energy levels to wireless nodes

You can set different initial energy to each wireless node separately. Your TCL script example is below.

set opt(initialenergy) 1000 ; # Initial energy in Joules

# Define Mobile Node Configurations
$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace ON \
-movementTrace ON \
-energyModel $opt(energymodel) \
-idlePower 1.0 \
-rxPower 1.0 \
-txPower 1.0 \
-sleepPower 0.001 \
-transitionPower 0.2 \
-transitionTime 0.005 \
-initialEnergy $opt(initialenergy)

....
....
set node_(0) [$ns node] # This will be generate node with initial energy 1000 Joules

$ns node-config -initialEnergy 500
set node_(1) [$ns node]


$ns node-config -initialEnergy 20
set node_(2) [$ns node]

$ns node-config -initialEnergy 30
set node_(3) [$ns node]

$ns node-config -initialEnergy 100
set node_(4) [$ns node]

...


You can find an example of 5 Nodes with different energy levels / AODV Routing Protocol in NS 2.35 below.
# wireless-qeaodv.tcl
# 5 Nodes with different energy levels / AODV Routing Protocol Example

# ======================================================================
# Define Values
# ======================================================================
set val(chan) Channel/WirelessChannel ;
set val(prop) Propagation/TwoRayGround ;
set val(ant) Antenna/OmniAntenna ;
set val(ll) LL ;
set val(ifq) Queue/DropTail/PriQueue ;
set val(ifqlen) 50 ;
set val(netif) Phy/WirelessPhy ;
set val(mac) Mac/802_11 ;
set val(rp) AODV ;
set val(nn) 5 ;
set opt(energymodel) EnergyModel ;
set opt(initialenergy) 1000 ; # Initial energy in Joules
set opt(lm) "off" ;# log movement
set opt(logenergy) "on" ;# log energy every 150 seconds

set val(x) 500 ;
set val(y) 500 ;
set val(stop) 60;
set filename $val(rp)_$val(nn)_$val(x)_$val(y);
set ns [new Simulator]

# open trace file
set tracefd [open $filename.tr w]
$ns trace-all $tracefd

#Open the nam trace file
set namtrace [open $filename.nam w]
$ns namtrace-all-wireless $namtrace $val(x) $val(y)


set WirelessNewTrace_ ON
#set AgentTrace ON
#set RouterTrace OFF
#set MacTrace ON

# ------------------------------------------------------------------------------
# Ağ topolojisi tanımı
# ------------------------------------------------------------------------------
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)

# General Operations Director (GOD)
create-god $val(nn)

# nn miktarınca düğüm [$val(nn)] oluştur ve kanala ilişkilendir.
set chan_1 [new $val(chan)]


# düğümleri konfigure et
$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace ON \
-movementTrace ON \
-energyModel $opt(energymodel) \
-idlePower 1.0 \
-rxPower 1.0 \
-txPower 1.0 \
-sleepPower 0.001 \
-transitionPower 0.2 \
-transitionTime 0.005 \
-initialEnergy $opt(initialenergy)

#for {set i 0} {$i < $val(nn) } { incr i } {
# set node_($i) [$ns node]
# $node_($i) random-motion 0 ;# disable random motion
#}

# Set initialEnergy values for Nodes
$ns node-config -initialEnergy 500
set node_(0) [$ns node]
$node_(0) color blue
$node_(0) shape box
$node_(0) label "Source"

# Set initial_node_pos
$node_(0) set X_ 40.0
$node_(0) set Y_ 280.0


$ns node-config -initialEnergy 500
set node_(1) [$ns node]

$ns node-config -initialEnergy 20
set node_(2) [$ns node]

$ns node-config -initialEnergy 20
set node_(3) [$ns node]

$ns node-config -initialEnergy 100
set node_(4) [$ns node]


# $node color [color] ;# sets color of node
# $node shape [shape] ;# sets shape of node
# $node label [label] ;# sets label on node
# $node label-color [lcolor] ;# sets color of label
# $node label-at [ldirection] ;# sets position of label
# $node add-mark [name] [color] [shape] ;# adds a mark to node
# $node delete-mark [name] ;# deletes mark from node

$node_(1) set X_ 420.0
$node_(1) set Y_ 280.0
$node_(1) color "red"
$node_(1) label "Destination"

$node_(2) set X_ 220.0
$node_(2) set Y_ 380.0
$node_(2) color "green"

$node_(3) set X_ 360.0
$node_(3) set Y_ 280.0
$node_(3) color "green"

$node_(4) set X_ 220.0
$node_(4) set Y_ 180.0
$node_(4) color "green"


for {set i 0} {$i < $val(nn) } { incr i } {
$ns initial_node_pos $node_($i) 30;
}


set udp [new Agent/UDP]
$ns attach-agent $node_(0) $udp
set null [new Agent/Null]
$ns attach-agent $node_(1) $null
$ns connect $udp $null
$udp set fid_ 1

set cbr [new Application/Traffic/CBR]
$cbr attach-agent $udp
$cbr set type_ CBR
$cbr set packetSize_ 48; # 48 byte 384bit
$cbr set rate_ 64000; # 0.064Mb || 64kb || 64000bit || bits per second
# interval_=0.0060000000000000001 || bit per second || 384/64000
# Packets in one second = 64000/384= 166,6packet

$cbr set random_ false


$ns at 10.0 "$cbr start"


for {set i 0} {$i < $val(nn) } { incr i } {
$ns at $val(stop) "$node_($i) reset";
}

$ns at 60.0 "$cbr stop"
# ------------------------------------------------------------------------------
# nam ve simulation end
# ------------------------------------------------------------------------------
# $ns at 15 "$node_(0) print_rtable"
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
#$ns at $val(stop) "$awk -f _packet.awk AODV_5_500_500.tr"
$ns at 70 "stop"
$ns at 70 "puts "end simulation" ; $ns halt"


proc stop {} {
global ns tracefd namtrace filename
$ns flush-trace
close $tracefd
close $namtrace
exec nam $filename.nam; #Execute nam on the trace file
exec awk -f _packet.awk $filename.tr
}

$ns run

Thursday, 4 July 2019

Basic Unix Commands



Knowing basic Unix commands should allow you to navigate your Unix or Linux system, confirm current system status and manage files or directories.

Getting help in Unix
man – view manual pages for Unix commands

Time and Date commands
date – show current date and time
sleep – wait for a given number of seconds
uptime – find out how long the system has been up

Unix users commands
These commands allow you to get basic information about Unix users in your environment.

id – print user identity
passwd – change user password
who – find out who is logged into the system
last – show history of logins into the system

Unix file operations
Navigating filesystem and managing files and access permissions:

ls – list files and directories
cp – copy files (work in progress)
rm – remove files and directories (work in progress)
mv – rename or move files and directories to another location
chmod – change file/directory access permissions
chown – change file/directory ownership

Text file operations in Unix
Most of important configuration in Unix is in clear text files, these commands will let you quickly inspect files or view logs:

cat – concatenate files and show contents to the standard output
more – basic pagination when viewing text files or parsing Unix commands output
less – an improved pagination tool for viewing text files (better than more command)
head – show the first 10 lines of text file (you can specify any number of lines)
tail – show the last 10 lines of text file (any number can be specified)

Unix directory management commands
Navigating filesystems and managing directories:

cd – change directory
pwd – confirm current directory
ln – make links and symlinks to files and directories
mkdir – make new directory
rmdir – remove directories in Unix

Unix system status commands
Most useful commands for reviewing hostname configuration and vital stats:

hostname – show or set server hostname
w – display system load, who's logged in and what they are doing
uname – print Unix system information

Networking commands in Unix
Most useful commands for inspecting network setup and exploring network connections and ports:

ifconfig – show and set IP addresses (found almost everywhere)
ip – show and set IP addresses (in recent Linux versions)
ping – check if remote host is reachable via ICMP ping
netstat – show network stats and routing information

Process management
Listing processes and confirming their status, and stopping processes if needed:

ps – list processes
top – show tasks and system status
kill – kill a process (stop application running)

Remote access commands
ssh is really the only way to go, but it's important to know telnet as well:

telnet – clear-text (insecure) remote access protocol
ssh – Secure SHell – encrypted remote access client

File transfers  commands
Always useful to know how to copy files between servers or just download some package from the web:

ftp – clear-text (insecure!) File Transfer Protocol client
sftp – secure (encrypted) version of FTP
scp – secure (encrypted) version of cp command
wget – download files from remote servers, HTTP/HTTPS and FTP

Basic UNIX commands


UNIX is case-sensitive.

Files

  • ls --- lists your files
    ls -l --- lists your files in 'long format', which contains lots of useful information, e.g. the exact size of the file, who owns the file and who has the right to look at it, and when it was last modified.
    ls -a --- lists all files, including the ones whose filenames begin in a dot, which you do not always want to see.
    There are many more options, for example to list files by size, by date, recursively etc.
  • more filename --- shows the first part of a file, just as much as will fit on one screen. Just hit the space bar to see more or q to quit. You can use /pattern to search for a pattern.
  • emacs filename --- is an editor that lets you create and edit a file. 
  • mv filename1 filename2 --- moves a file (i.e. gives it a different name, or moves it into a different directory (see below)
  • cp filename1 filename2 --- copies a file
  • rm filename --- removes a file. It is wise to use the option rm -i, which will ask you for confirmation before actually deleting anything. 
  • diff filename1 filename2 --- compares files, and shows where they differ
  • wc filename --- tells you how many lines, words, and characters there are in a file
  • chmod options filename --- lets you change the read, write, and execute permissions on your files. The default is that only you can look at them and change them, but you may sometimes want to change these permissions. For example, chmod o+r filename will make the file readable for everyone, and chmod o-r filename will make it unreadable for others again. Note that for someone to be able to actually look at the file the directories it is in need to be at least executable. See help protection for more details.
  • File Compression
    • gzip filename --- compresses files, so that they take up much less space. Usually text files compress to about half their original size, but it depends very much on the size of the file and the nature of the contents. There are other tools for this purpose, too (e.g. compress), but gzip usually gives the highest compression rate. Gzip produces files with the ending '.gz' appended to the original filename.
    • gunzip filename --- uncompresses files compressed by gzip.
    • gzcat filename --- lets you look at a gzipped file without actually having to gunzip it (same as gunzip -c). You can even print it directly, using gzcat filename | lpr
  • printing
    • lpr filename --- print. Use the -P option to specify the printer name if you want to use a printer other than your default printer. For example, if you want to print double-sided, use 'lpr -Pvalkyr-d', or if you're at CSLI, you may want to use 'lpr -Pcord115-d'. See 'help printers' for more information about printers and their locations.
    • lpq --- check out the printer queue, e.g. to get the number needed for removal, or to see how many other files will be printed before yours will come out
    • lprm jobnumber --- remove something from the printer queue. You can find the job number by using lpq. Theoretically you also have to specify a printer name, but this isn't necessary as long as you use your default printer in the department.
    • genscript --- converts plain text files into postscript for printing, and gives you some options for formatting. Consider making an alias like alias ecop 'genscript -2 -r \!* | lpr -h -Pvalkyr' to print two pages on one piece of paper.
    • dvips filename --- print .dvi files (i.e. files produced by LaTeX). You can use dviselect to print only selected pages. .

Directories

Directories, like folders on a Macintosh, are used to group files together in a hierarchical structure.
  • mkdir dirname --- make a new directory
  • cd dirname --- change directory. You basically 'go' to another directory, and you will see the files in that directory when you do 'ls'. You always start out in your 'home directory', and you can get back there by typing 'cd' without arguments. 'cd ..' will get you one level up from your current position. You don't have to walk along step by step - you can make big leaps or avoid walking around by specifying path names
  • pwd --- tells you where you currently are.

Finding things

  • ff --- find files anywhere on the system. This can be extremely useful if you've forgotten in which directory you put a file, but do remember the name. In fact, if you use ff -p you don't even need the full name, just the beginning. This can also be useful for finding other things on the system, e.g. documentation.
  • grep string filename(s) --- looks for the string in the files. This can be useful a lot of purposes, e.g. finding the right file among many, figuring out which is the right version of something, and even doing serious corpus work. grep comes in several varieties (grepegrep, and fgrep) and has a lot of very flexible options. Check out the man pages if this sounds good to you.

About other people

  • w --- tells you who's logged in, and what they're doing. Especially useful: the 'idle' part. This allows you to see whether they're actually sitting there typing away at their keyboards right at the moment.
  • who --- tells you who's logged on, and where they're coming from. Useful if you're looking for someone who's actually physically in the same building as you, or in some other particular location.
  • finger username --- gives you lots of information about that user, e.g. when they last read their mail and whether they're logged in. Often people put other practical information, such as phone numbers and addresses, in a file called .plan. This information is also displayed by 'finger'.
  • last -1 username --- tells you when the user last logged on and off and from where. Without any options, last will give you a list of everyone's logins.
  • talk username --- lets you have a (typed) conversation with another user
  • write username --- lets you exchange one-line messages with another user
  • elm --- lets you send e-mail messages to people around the world (and, of course, read them). It's not the only mailer you can use, but the one we recommend. 

About your (electronic) self

  • whoami --- returns your username. Sounds useless, but isn't. You may need to find out who it is who forgot to log out somewhere, and make sure *you* have logged out.
  • finger & .plan files
    of course you can finger yourself, too. That can be useful e.g. as a quick check whether you got new mail. Try to create a useful .plan file soon. Look at other people's .plan files for ideas. The file needs to be readable for everyone in order to be visible through 'finger'. Do 'chmod a+r .plan' if necessary. You should realize that this information is accessible from anywhere in the world, not just to other people on turing.
  • passwd --- lets you change your password, which you should do regularly (at least once a year). 
  • ps -u yourusername --- lists your processes. Contains lots of information about them, including the process ID, which you need if you have to kill a process. Normally, when you have been kicked out of a dialin session or have otherwise managed to get yourself disconnected abruptly, this list will contain the processes you need to kill. Those may include the shell (tcsh or whatever you're using), and anything you were running, for example emacs or elm. Be careful not to kill your current shell - the one with the number closer to the one of the ps command you're currently running. But if it happens, don't panic. Just try again :) If you're using an X-display you may have to kill some X processes before you can start them again. These will show only when you use ps -efl, because they're root processes.
  • kill PID --- kills (ends) the processes with the ID you gave. This works only for your own processes, of course. Get the ID by using ps. If the process doesn't 'die' properly, use the option -9. But attempt without that option first, because it doesn't give the process a chance to finish possibly important business before dying. You may need to kill processes for example if your modem connection was interrupted and you didn't get logged out properly, which sometimes happens.
  • quota -v --- show what your disk quota is (i.e. how much space you have to store files), how much you're actually using, and in case you've exceeded your quota (which you'll be given an automatic warning about by the system) how much time you have left to sort them out (by deleting or gzipping some, or moving them to your own computer).
  • du filename --- shows the disk usage of the files and directories in filename (without argument the current directory is used). du -s gives only a total.
  • last yourusername --- lists your last logins. Can be a useful memory aid for when you were where, how long you've been working for, and keeping track of your phonebill if you're making a non-local phonecall for dialling in.

Connecting to the outside world

  • nn --- allows you to read news. It will first let you read the news local to turing, and then the remote news. If you want to read only the local or remote news, you can use nnl or nnr, respectively. To learn more about nn type nn, then \tty{:man}, then \tty{=.*}, then \tty{Z}, then hit the space bar to step through the manual. Or look at the man page. Or check out the probably the easiest and most fun way to go.
  • rlogin hostname --- lets you connect to a remote host
  • telnet hostname --- also lets you connect to a remote host. Use rlogin whenever possible.
  • ftp hostname --- lets you download files from a remote host which is set up as an ftp-server. This is a common method for exchanging academic papers and drafts. If you need to make a paper of yours available in this way, you can (temporarily) put a copy in /user/ftp/pub/TMP. For more permanent solutions, ask Emma. The most important commands within ftp are get for getting files from the remote machine, and put for putting them there (mget and mput let you specify more than one file at once). Sounds straightforward, but be sure not to confuse the two, especially when your physical location doesn't correspond to the direction of the ftp connection you're making. ftp just overwrites files with the same filename. If you're transferring anything other than ASCII text, use binary mode.
  • lynx --- lets you browse the web from an ordinary terminal. Of course you can see only the text, not the pictures. You can type any URL as an argument to the G command. When you're doing this from any Stanford host you can leave out the . part of the URL when connecting to Stanford URLs. Type H at any time to learn more about lynx, and Q to exit.

Miscellaneous tools

  • webster word --- looks up the word in an electronic version of Webster's dictionary and returns the definition(s)
  • date --- shows the current date and time.
  • cal --- shows a calendar of the current month. Use e.g., 'cal 10 1995' to get that for October 95, or 'cal 1995' to get the whole year.
You can find out more about these commands by looking up their manpages:
man commandname --- shows you the manual page for the command

Basics of UNIX


Main features of unix :
1.      Multi user -  More than one user can use the machine
2.      Multitasking- More than one program can be run at a time.
3.      Portability – This means  the operating system can be easily converted to run on different browsers.
Commands
ls         
when invoked without any arguments, lists the files in the current working directory. A directory that is not the current working directory can be specified and ls will list the files there. The user also may specify any list of files and directories. In this case, all files and all contents of specified directories will be listed.
Files whose names start with "." are not listed, unless the -a flag is specified or the files are specified explicitly.
Without options, ls displays files in a bare format. This bare format however makes it difficult to establish the type, permissions, and size of the files. The most common options to reveal this information or change the list of files are:
-l    long format, displaying Unix file type, permissions, number of hard links, owner,     group, size, date, and filename
-F    appends a character revealing the nature of a file, for example, * for an executable, or / for a directory. Regular files have no suffix.
-a  lists all files in the given directory, including those whose names start with "." By default, these files are excluded from the list.
-R  recursively lists subdirectories. The command ls -R / would therefore list all files.
cd
Is a command line command used to change the current working directory in the Unix and DOS operating systems. It is also available for use in Unix shell scripts or DOS batch files. cd is frequently included built into certain shells such as the Bourne shell, tcsh, bash (where it calls the chdir() POSIX C function) and in DOS's COMMAND.COM.
A directory is a logical section of a filesystem used to hold files. Directories may also contain other directories. The cd command can be used to change into a subdirectory, move back into the parent directory, move all the way back to the root (/ in UNIX, \ in DOS) or move to any given directory.
pwd
command (print working directory) is used to print the name of current working directory from a computer's command-line interface. If the shell prompt does not already show this, the user can use this command to find their place in the directory tree. This command is found in the Unix family of operating systems and other flavors as well. The DOS equivalent is "CD" with no arguments.
It is a command which is sometimes included built into certain shells such as sh, and bash. It can be implemented easily with the POSIX C functions getcwd() and/or getwd().
Example:
$ pwd
/home/foobar
mkdir
command in the Unix operating system is used to make a new Directory. Normal usage is as straightforward as follows:
mkdir name_of_directory
Where name_of_directory is the name of the directory one wants to create. When typed as above (ie. normal usage), the new directory would be created within the current directory.
rm (short for remove)
is a Unix command used to delete files from a filesystem. Common options that rm accepts include:
-r, which processes subdirectories recursively
-i, which asks for every deletion to be confirmed
-f, which ignores non-existent files and overrides any confirmation prompts ("force")
rm is often aliased to "rm -i" so as to avoid accidental deletion of files. If a user still wishes to delete a large number of files without confirmation, they can manually cancel out the -i argument by adding the -f option.
"rm -rf" (variously, "rm -rf /", "rm -rf *", and others) is frequently used in jokes and anecdotes about Unix disasters. The "rm -rf /" variant of the command, if run by an administrator, would cause the contents of every mounted disk on the computer to be deleted.
rmdir
is a command which will remove an empty directory on a Unix-system. It cannot be capitalized. Normal usage is straightforward where one types:
rmdir name_of_directory
Where name_of_directory corresponds with the name of the directory one wishes to delete. There are options to this command such as -p which removes parent directories if they are also empty.
For example:
rmdir –p foo/bar/baz
Will first remove baz/, then bar/ and finally foo/ thus removing the entire directory tree specified in the command argument.
Often rmdir will not remove a directory if there is still files present in the directory. To force the removal of the directory even if files are present usually the -rf flag can be used. For example:
rmdir -Rf for/bar/baz
cp
is the command entered in a Unix shell to copy a file from one place to another, possibly on a different filesystem. The original file remains unchanged, and the new file may have the same or a different name.
To Copy a File to another File
cp [ -f ] [ -h ] [ -i ] [ -p ][ -- ] SourceFile TargetFile
To Copy a File to a Directory
cp [ -f ] [ -h ] [ -i ] [ -p ] [ -r | -R ] [ -- ] SourceFile ... TargetDirectory
To Copy a Directory to a Directory
cp [ -f ] [ -h ] [ -i ] [ -p ] [ -- ] { -r | -R } SourceDirectory ... TargetDirectory
-f (force) – specifies removal of the target file if it cannot be opened for write operations. The removal precedes any copying performed by the cp command.
-h – makes the cp command copy symbolic links. The default is to follow symbolic links, that is, to copy files to which symbolic links point.
-i (interactive) – prompts you with the name of a file to be overwritten. This occurs if the TargetDirectory or TargetFile parameter contains a file with the same name as a file specified in the SourceFile or SourceDirectory parameter. If you enter y or the locale's equivalent of y, the cp command continues. Any other answer prevents the cp command from overwriting the file.
-p (preserve) – duplicates the following characteristics of each SourceFile/SourceDirectory in the corresponding TargetFile and/or TargetDirectory:
Examples
To make a copy of a file in the current directory, enter:
    cp prog.c prog.bak
This copies prog.c to prog.bak. If the prog.bak file does not already exist, the cp command creates it. If it does exist, the cp command replaces it with a copy of the prog.c file.
To copy a file in your current directory into another directory, enter:
    cp jones /home/nick/clients
This copies the jones file to /home/nick/clients/jones.
To copy a file to a new file and preserve the modification date, time, and access control list associated with the source file, enter:
    cp -p smith smith.jr
This copies the smith file to the smith.jr file. Instead of creating the file with the current date and time stamp, the system gives the smith.jr file the same date and time as the smith file. The smith.jr file also inherits the smith file's access control protection.
To copy all the files in a directory to a new directory, enter:
    cp /home/janet/clients/* /home/nick/customers
This copies only the files in the clients directory to the customers directory.
To copy a directory, including all its files and subdirectories, to another directory, enter:
    cp -R /home/nick/clients /home/nick/customers
This copies the clients directory, including all its files, subdirectories, and the files in those subdirectories, to the customers/clients directory.
To copy a specific set of files to another directory, enter:
    cp jones lewis smith /home/nick/clients
This copies the jones, lewis, and smith files in your current working directory to the /home/nick/clients directory.
To use pattern-matching characters to copy files, enter:
    cp programs/*.c .
This copies the files in the programs directory that end with .c to the current directory, signified by the single . (dot). You must type a space between the c and the final dot.
find
program is a search utility, mostly found on Unix-like platforms. It searches through a directory tree of a filesystem, locating files based on some user-specified criteria. By default, find returns all files below the current working directory. Further, find allows the user to specify an action to be taken on each matched file. Thus, it is an extremely powerful program for applying actions to many files. It also supports regexp matching.
Examples
From current directory
find . -name my\*
This searches in the current directory (represented by a period) and below it, for files and directories with names starting with my. The backslash before the star is needed to avoid the shell expansion. Without the backslash, the shell would replace my* with the list of files whose names begin with my in the current directory. An alternative is to enclose the the arguments in quotes: find . -name "my*"
Files only
find . -name "my*" -type f
This limits the results of the above search to only regular files, therefore excluding directories, special files, pipes, symbolic links, etc. my* is enclosed in quotes as otherwise the shell would replace it with the list of files in the current directory starting with my
Commands
The previous examples created listings of results because, by default, find executes the '-print' action. (Note that early versions of the find command had no default action at all; therefore the resulting list of files would be discarded, to the bewilderment of naïve users.)
find . -name "my*" -type f -ls
This prints an extended file information.
Search all directories
find / -name "myfile" -type f -print
This searches every file on the computer for a file with the name myfile. It is generally not a good idea to look for data files this way. This can take a considerable amount of time, so it is best to specify the directory more precisely.
Specify a directory
find /home/brian -name "myfile" -type f -print
This searches for files named myfile in the /home/brian directory, which is the home directory for the user brian. You should always specify the directory to the deepest level you can remember.
Find any one of differently named files
find . ( -name "*jsp" -or -name "*java" ) -type f -ls
This prints extended information on any file whose name ends with either 'jsp' or 'java'. Note that the parentheses are required. Also note that the operator "or" can be abbreviated as "o". The "and" operator is assumed where no operator is given. In many shells the parentheses must be escaped with a backslash, "\(" and "\)", to prevent them from being interpreted as special shell characters.
touch
is a program on Unix and Unix-like systems used to change a file's date- and time-stamp. It can also be used to create an empty file. The command-syntax is:
touch [options] <file_name>
If the file exists, its access and modification time-stamps are set to the system's current date and time, as if the file had been changed. To touch a file simulates a change to the file. If the file does not exist, an empty file of that name is created with its access and modification time-stamps set to the system's current date and time. If no file path is specified, the current directory is assumed.
touch can be invoked with options to change its behaviour, which may vary from one Unix to another. One option makes it possible to set the file's time-stamp to something other than the current system date and time, but this action is normally restricted to the owner of the file or the system's superuser.
echo
is a command in Unix (and by extension, its descendants, such as Linux) and MS-DOS that places a string on the terminal. It is typically used in shell scripts and batch programs to output status text to the screen or a file.
$ echo This is a test.
This is a test.
$ echo "This is a test." > ./test.txt
$ cat ./test.txt
This is a test.
cat
program concatenates the contents of files, reading from a list of files and/or standard input in sequence and writing their contents in order to standard output. cat takes the list of files as arguments but also interprets the argument "-" as standard input.
 Example:          cat  filename
who                         
The Unix command who displays a list of users who are currently logged into a computer. The command accepts various options that vary by system to further specify the information that is returned, such as the length of time a particular user has been connected or what pseudo-teletype a user is connected to. The who command is related to the command w, which provides the same information but also displays additional data and statistics.
Example output         
user19    pts/35       Apr 18 08:40    (localhost)
user28    pts/27       Apr 18 09:50    (localhost)
du (abbreviated from disk usage)
is a Unix computer program to display the amount of disk space used under a particular directory or files on a file system.
du counts the disk space by walking the directory tree. As such, the amount of space on a file system shown by du may vary from that shown by df if files have been deleted but their blocks not yet freed.
In Linux, it is a part of the GNU Coreutils package.
The du utility first appeared in version 1 of AT&T UNIX.
Example
The -k flag will show the sizes in 1K blocks, rather than the default of 512 byte blocks.
$du -k /seclog
4       /seclog/lost+found
132     /seclog/backup/aix7
136     /seclog/backup
44044   /seclog/temp
439264  /seclog