Transition Simulators

VASP simulator vobs/ae_apps/ae_tools/vaspSimulator $ ./vaspSimulator vaspConfig.cfg The VASP simulator can send or receive MM7 messages to or from the ASI. For the simulator to receive messages, you must set destUrl and reportUrl in ipcmanager.cfg to match ServerHostPort in vaspConfig.cfg. To make the VASP simulator send messages, set SendVaspMessages=1 in vaspConfig.cfg. Some other commonly used configuration options are: ManagementHostPort Point a web browser at this port to see some important stats. VaspMessageRate This is the rate at which you want messages to be retrieved and, in conjunction the configuration item RecipientsPattern, is the aggregate rate at which they will be sent. For example, if VaspMessageRate is set to 100 and the RecipientsPattern is set to 10, then the VASP simulator will inject 10 messages per second into ASI (10 messages with 10 recipients is 100 msg/s). If VaspMessageRate is set to 100 and the RecipientsPattern is set to 1000, then the simulator will send one message with 1000 recipients, then wait 10 seconds before sending the next message. Note that specifying a message rate does not necessarily mean that this message rate will be achieved. This is really only an issue to higher message rate tests. When perfoming tests at high message rate (ie load testing and benchmarking), you will need to verify using the ASI management page that the correct rates are being achieved. You can also see the achieved message submission rate (both actual and aggregate) in the VASP simulator’s management page. VaspMaxNumOfMessages The maximum number of messages you want the VASP simulator to send. Once it has sent this many, it will stop sending, but the vaspSimulator process will continue to run. If you want the simulator to keep sending until the process is killed, set this value to 0. VASP_List This allows the simulator to act as multiple VASPs. Use this option if you want to send messages with different payloads. There are several options in vaspConfig.cfg whose names start with “VASP_1”. If you’re going to be using multiple VASPs, then all your additional VASPs (VASP_2, VASP_3, etc.) will need their own copies of all these

options. Warning: I never used more than one VASP at a time myself, and I don’t know all the details about how to set this up properly. VASP_1.MessagePayloadFilename The filename of the .mms file you’ll be using as a payload. VASP_1.SenderAddr The Sender address that will appear in your MM7_submit.REQ messages. It should match the Reply-To address. VASP_1.RecipientBaseAddr All recipient addresses will be based on this prefix (see the comments in vaspConfig.cfg for more information). Make sure your pa.cfg is set up so that your messages are routed to the proper receiving PA. VASP_1.RecipientsPattern Here is where you set how many recipients your messages will have. If you put just one number here, all messages will have the same number of recipients. If you put a space separated sequence of numbers, the simulator will cycle through the list. This means the waiting time between sendings will also change – see the discussion of VaspMessageRate above. MM7 test scripts vobs/ae_apps/asi/MM7Testing/ ./submit_one.pl ADDRESS PORT FILENAME This is a collection of Perl scripts, each of which sends a different type of MM7 message to the ASI. You can manipulate the XML content of a message by editing the script’s source code. Each script uses command-line parameters. For example, to use the submit_one.pl script shown above (which sends a single MM7_submit.REQ), you need to provide the IP address and port number of your ASI, plus the .mms filename of the multimedia message you want to submit. For cancel_one.pl, you need to provide the same information, plus the Message ID number of the message you’re replacing. Running the scripts with invalid or with no command line options will print out what is required. When you run one of these scripts, it will dump the content of ASI’s response to the console. You can get useful information from this, like Message ID numbers or error codes. These scripts are meant for single-message tests. To send a constant stream of messages, use the VASP simulator.

SMSC simulator vobs/ae_apps/amf/smsc_server ./smsc_server -smpp-server-port PORT -http-server-port PORT -forward-wap -wapserver-host IP_ADDRESS -wap-server-port PORT & This acts as an SMSC server, forwarding SIRs and other messages from SMPPAM to a handset sim. Unlike a real SMSC server, the simulator does not support retries; the handset must be online to receive the SIR as soon as it’s sent. If you’re running a test in which the handset is initially switched off, you need to simulate that by setting your handset sim to have a very long delay. smpp-server-port This is the port smsc_server will listen on. Make sure smpp_am.cfg is configured to send to this port. http-server-port The SMSC simulator does not have a management page. Just assign this to an available port number. It’s not actually used. wap-server-host wap-server-port The IP address of the handset simulator, and the port it will be listening on. This must match the ServerHostPort of the handset simulator. SIRs and other messages will be forwarded to this address/port. Unlike a real SMSC server, an SMSC simulator cannot send to more than one handset. All your configuration is done on the command line. There is a smsc_server.cfg file, and the simulator won’t run if it’s not present, but there’s nothing in it that you should ever need to edit. Handset simulator vobs/ae_apps/ae_tools/handsetSimulator ./handset-simulator handsetSimulator.cfg The handset simulator acts as one or more handsets. It receives SIRs and other notifications from the MMSC, routed through the SMSC simulator. It also sends requests to the MMSC’s MM1AM. It does not send P2P multimedia messages (there are other tools for that), but it can retrieve messages stored in MMM, and send read replies. Commonly used configuration options:

ServerHostPort The simulator will listen on this port for messages routed through SMSC. This must match the wap-server-host and wap-server-port used to configure the SMSC simulator. ManagementHostPort Point a web browser at this address to see various important stats. DefaultMMSCURL The handset sim will send all of its notifications, acknowledgements, read replies, and possibly retrieval requests (see RetrieveFromDefaultMMSC configuration item) to this address/port. Make sure it’s pointed to your MM1AM ServerHostPort defined in mm1am.cfg, or the MM1 router if you’re using one. RetrieveFromDefaultMMSC If this is set to 1, then the handset will always attempt to retrieve multimedia messages by sending a HTTP request to the DefaultMMSCURL. If you set it to 0, then the handset will look in the SIR to find the proper retrieval address. Either way, all MM1 notify and acknowledgement messages will still be sent to the default MMSC URL. ClientThreads The number of MM1 client threads you’ll be running. For A2P, this should match the number of threads in MM1AM. When running a stress test, finding the proper number of threads to run can be tricky. The more threads your handset sim is running, the more messages per second you can process. However, additional threads make more work for the processor. The type of machine you’re running the system on also makes a difference. I suggest you start with a small number, like 10, and gradually increase it until you find a number that can handle the load you want. The default of 200 is way too high – you’ll never need that many. SMSCDelay When the handset receives a SIR, it will wait this many seconds before responding. This simulates the time it would take for the SMSC server to forward the SIR to the handset, and should never be set to a value less that 2 seconds. DelaySequence This is where you configure the handset simulator for immediate or deferred retrieval. DelaySequence can be a single value, or a series of values that the simulator will cycle through. If the delay is 0, the handset will retrieve the multimedia message immediately. If it’s greater than 0, then the retrieval will be deferred by this many seconds. It’s possible that the multimedia message could expire from MMM before that happens. EnableReport EnableReadReport Set these to 1 to allow delivery reports and read replies, respectively.

ReadReportDelay This represents the time delay between acknowledging a message, and sending the read reply. It *must* be greater than zero. If it’s set to zero, then the MMSC might get the read reply before the message is acknowledged, which isn’t possible in a real-world environment. STI Simulator vobs/ae_apps/ae_tools/stiSimulator ./stiSimulator webServer.cfg The STI simulator is used when testing external transcoding. Keep in mind that the STI simulator doesn’t actually do any transcoding and simply passes back the payload it receives. StiDelaySequence Set the transcoding delay, in milliseconds. For most tests, you’ll only need one value here. ServerHostPort Make sure MM1AM is configured to send external transcoding requests to this address (transcodingHostPort in the mm1am.cfg #External Transformation Server settings). SMTP Sink vobs/ae_apps/ae_tools/postfix-2.2.2/src/smtpstone This is a third-party tool for testing software that uses SMTP. Note that this tool is not compiled daily and that the Solaris 9 Sparc binaries are what are stored in ClearCase. ./smtp-sink –v IP_ADDRESS:PORT 100 > /dev/null & Configure your MM4AM to send to this address and port. The sink will receive an SMTP message, print out a summary, and throw the message away. It cannot send delivery reports or read reply reports back to MM4AM (we do not currently have a tool to do this). MM4 injector We use a shell script that opens a telnet connection to the MMSC’s SMTP_Server and forwards a message. For a constant stream of messages, write another shell script that uses a loop to continuously call the inject script.

MM1 encoder vobs/ae_apps/ae_tools/mm1suite/ ./mm1encoder mm1encoder.cfg This utility encodes MM1 binary PDUs and can be used to encode and inject single messages into MM1AM on-the-fly using a configuration file. Commonly used config options: outputMethod outputFile outputHost outputPort These options determine what the encoder will do with the output binary message. If outputMethod is set to FILE, then the message will be dumped to a filename specified by outputFile. If outputMethod is set to NETWORK, then the message will be sent over the network to the IP address and port number specified by outputHost and outputPort; these should be set to point at your MM1AM. mmFiles mmTypes Here you list the file(s) that will make up the multimedia message, and their associated types. See the comments in the config file for more information. mmsMessageType The type of MM1 message you’re going to send. For most tests, this will be MESSAGE_TYPE_M_SEND_REQ, which translates to MM1_submit.REQ. You’ll also need to set the header values appropriate to the type of message you are sending. All the options are well-documented in comments in the config file. MM1 decoder vobs/ae_apps/ae_tools/mm1suite/ ./mm1decoder-input <MM1 binary PDU file> -output

Note that the –output command line option is optional, and if it is not present the contents will be dumped to the current directory.

This utility will take in an MM1 binary PDU file and dump its contents to do disk. The output files include an output_config.cfg file that contains the header information of the binary PDU, and a series of A<#> files containing to the multimedia components of the message. For example, running the decoder on a PDU that contains two images will result in three files being generated: the output_config.cfg and two image files named as A0 and A1. The output file types will be output to screen. The output_config.cfg is a valid mm1 encoder configuration file and can be used to regenerate an MM1 binary PDU of the same type using the mm1 encoder discussed above. MMSC Simulator Source in /ae_apps/mm1am/mmscSimulator Binaries altered for Benchmarking on Memphis 1&2 at: /opt/loadtest/sims/Simulator_intel The MMSC Simulator is used to inject an MM1 binary PDU into MM1AM at a configurable rate and is normally used for load testing. To use the mmscSimulator to inject binaries into mm1am, you need the following files: -mmscServer -pminit.env -runSimulator.sh (not required but useful) -webServer.cfg -mmsc.cfg -binary MM1 send req that does NOT have headers (it will work if it has them, but there is no point in them being there) The following items need to be set in the mmsc.cfg file: defaultMmsc.Host = Host address of MM1AM defined in mm1am.cfg defaultMmsc.EgressPort = Port address of MM1AM defined in mm1am.cfg defaultMmsc.URL = /mmsc/ defaultMmsc.Send-Mo = 1 # MoMessageRate msg/sec defaultMmsc.MoMessageRate = <message injection rate into MM1AM (in msg/s) # MoExecuteTime in hours , MoExecuteTime == 0 forever defaultMmsc.MoExecuteTime = 1 #Used when sending file that does not have headers defaultMmsc.UseHardCodedHeaders = 1 To run the mmscSimulator use the following commands:

source pminit.env # Usage: mmscServer webServer.cfg mmsc.cfg threads [inputFile] hostname port manage_object_name –1 For example, when injecting a binary PDU named mm1_mm1_NO_DR_NO_RR.bin_100k into an MMSC on fire3 with MM1AM port 30639, the command is: ./mmscServer webServer.cfg mmsc.cfg 2 mm1_mm1_NO_DR_NO_RR.bin_100k fire3 30639 fire3.generic.webserver -1 The runSimulator.sh file has these commands in it. As with the VASP simulator, specifying a rate does not necessarily mean that it will inject at that rate. Use the MM1AM management page to verify the rates. Finally, the changes for benchmarking have not been checked in so you will need to use the files on Memphis2 in the /opt/loadtest/sims/Simulator_intel directory.