How to select the appropriate protocol when recording scripts with LoadRunner

Reprinted 1 "
To properly select a protocol, familiarize yourself with the technical architecture of the application being tested. Some of the protocols supported by Loadrounner are listed below:

General application: C VUser, VB VUser, VB Script vuser, Javavuser, JavaScript. VUser
Ecommerce: WEB (http/html), FTP, LDAP, Palm, Web/winsocketdual Protocol
Client/server: MSSQLServer, ODBC, Oracle, DB2, Sybase ctlib, Sybase DBlib, Domain Name Resolution (DNS), Windows sockets
Distributed components: com/dcom, Corba-java, Rmi_java
EJB:EJB, Rmi_java
Erp/crp:oracle NCA, Sap-web, SAPgui, Sapgui/sap-web Dual Protocol, Proplesoft_tuxedo, Siebel Web, Siebel-db2 CLI, Sieble-mssql, Sieble Oracle
Legacy system: Terminal Emulation (RTE)
Mail Services: Internet Messaging (IMAP), MS Exchange (MAPI), POP3, SMTP
Middleware: Jacada, Tuxedo 6, Tuxedo 7
Wireless system: I-mode, VoiceXML, WAP
Application deployment software: Citrix_ica streaming: Media Plays (MMS), Real
"Reprint 2"
A classic solution protocol chosen for the LoadRunner protocol is the structural pattern in which data is transmitted over the network. The structure of the data message varies with the protocol. The protocol is hierarchical, generally we start with the IP layer, the TCP protocol layer, the UDP protocol layer, and the TCP and UDP protocol layer has the HTTP protocol layer, the FTP protocol layer, the SMTP protocol layer, and so on we see in LR the application layer of the Protocol. In fact, these high-level protocols are a further encapsulation of the underlying protocol. To give a simple example, the IP protocol data message is unordered, not reliable transmission, in its data message outside the message sequence, message status and other data segments constitute the TCP protocol layer. So many of our web applications, not finding the right protocol, are using Winsock to record, which is certainly no problem. Since almost all network transmissions are based on TCP protocol or UDP protocol, socket is the concept at this level. But because the socket protocol level is too low, what you recorded is hard to understand, it is socket,port,data and other things. So, we try to use the high-level protocol to record, we can read it.

Say it again to solve the specific problem. We see a software architecture, how to choose the recording protocol. Speaking of which, I would like to talk about my understanding of the LR recording mechanism (I have not contacted the LR kernel, just by guessing and inferring). When recording, LR should intercept the data you sent from the local computer and remove the package. Because we know that the difference between the protocol is reflected in the structure of the packet is different, LR should pass the analysis of the packet structure, determine whether it supports the protocol, the packet data analysis, to get the user to send something. For example, you use the FTP protocol to record a visit to the Web page of IE operation, it must be nothing to gain. Because LR does not intercept the packet in the network to the FTP protocol format, it is an HTTP protocol format package, it does not recognize, of course, is a record empty results. Now that we understand the matter, we know how to choose the protocol. See a lot of people care about LR is not supported by MySQL protocol. I think the idea of finding the answer is this:

1, first understand the MySQL protocol and other database protocol relationship, see if you can use other database protocol recording. But in fact, Oracle's CS protocol is unique to Oracle's own development of the protocol, SQL Server is the same, and MySQL and these major products are not subordinate relationship, its script recording is very unlikely.
2, the bottom of the MySQL protocol is based on what protocol, if directly built on the TCP protocol, LR does not support the MySQL protocol, it can only consider a lower protocol recording, that is, the socket. If the MySQL protocol is built on the ODBC protocol, it may be written in LR's ODBC API.
"Reprint 3"

Many times when it comes to not browser-based applications, many people think of recording with the WinSocket protocol, as if the form can be winsocket. In principle, the bottom of the network communication is based on sockets, such as TCP, UPD, and so on, it seems that all programs can be recorded with the socket protocol. But this is not the case, because the chosen protocol determines how the LoadRunner captures the packet. Otherwise, you'll catch a lot more useless data. Therefore, not all programs are suitable for the WinSocket protocol. In fact, applications based on socket development are really suitable for the socket protocol for recording. Others, such as database-based applications, are less likely to have a socket protocol, and may not even be able to record scripts. Many C/s programs, be sure to choose the appropriate protocol. According to the author's experience, the C/s program most need to manually develop a lot of scripts, because the recording of a lot of playback time will be more or less problems, but can refer to the results of the recording. So test a program and be sure to figure out what technology the developer used and what the data flow protocol encapsulates. Theoretically, before we perform a performance test on a system, we need to know what technologies they are using in the development process, what protocols are used to encapsulate the data flow, and how the network structure of the system we want to test, the configuration of the server, and so on. There is also the need to know the protocol between the system client and the first server, which involves a middleware problem. Also, we need to know that the choice of protocol is directly related to what packets the LR captures. These are the basis for performance testing. The following is a few of the principles of testing (all of them have encountered, hehe, have not met the Do not know):

1, in general, B/s framework as long as the choice of Web (http/html) protocol can be, if there is middleware to choose the Middleware server protocol;
2, c/s structure, can be based on the type of back-end database to choose. such as the SYBASECTLIB protocol used to test the background of the database for Sybase applications, MS SQL Server protocol with the test background database for SQL Server applications,
3, generally not browser-based, for some Windows applications without a database, We will choose the WinSocket protocol to record in the course of testing, in theory we choose is correct, but we need to know that when recording the protocol selected determines how LR captures the packet, if we choose the wrong, we will catch some useless packets. CS structure is relatively complex, here I would like to remind you, we must make it clear that CS is client-database or client-server-database structure, only in this way can we decide to choose WinSocket protocol or SQL protocol, or choose multiple protocols; Of course, the choice of protocol is also a process of exploration, as long as we can get the results we want, it is right. There is a point, we are doing performance testing should be the focus of testing, hehe.
4, about the single Protocol and the dual protocol, I only know that the browser of the IE6 kernel chooses a single protocol when recording a script, while the IE7 kernel's browser uses a dual protocol when recording a script.