In the old API the counters where returned in key-value lists. e.g. You needed to parse the list before you could retrieve your value
Returns:
NrOfFrames 84
using foreach {name value} or lindex it was possible to extract that result.
In API 2.x we've changed that to result objects. This allows you to get the value of the counter directly whitout the need of parsing a list. These result object contain also other resultmetrics that help in understanding what you measure e.g. framesizeMin and framesizeMax
In order to retrieve new counters you call the refresh method. Rx.Trigger.Basic.ResultData is the resultObject from a BasicTrigger.
New in 2.x API are the History Results. Each second we create 2 counter snapshots, one Cumulative and one Interval snapshot. Only the last 6 snapshots are kept in memory at server-side and can be requested. These results are useful to create some statitics over time.
The resulting ResultHistory object contains two lists of counter result objects. One list for the Cumulative snapshots and one containing the Interval snapshots. Each time you refresh this object, it will request up to 6 snapshots for each type from the server and are stored localy. The Clear method on the ResultHistory object will erase the local stored snapshots.
The result history is maintained locally and updated when the Refresh method is called.
By default, the server is configured with a sampling interval duration of 1 second and a sampling buffer length of 6 snapshot. The server maintains the last 6 snapshots of 1 second. So it can buffer the results for 6 seconds. If the server buffer runs full, it will drop the oldest result as a consequence.
When the user obtains the results after the server's buffer became full, the snapshots older than current time minus 6 seconds will be lost. The local history will then have a gap between previous refresh time and current time minus 6 seconds.
As a user, you probably want to have a continuous history of results, without any gaps in time. It is up to the user to make sure that the results are obtained before the buffer of the server runs full.
By default, the refresh interval should be smaller than 6 seconds. Because of timing issues when working at the edge, we advise to keep the refresh interval lower than 5 seconds. The Tcl-HL examples mainly use a refresh interval of 1 second.
A refresh interval less than the sampling interval duration is pretty useless since it will only update the last snapshot in the history (which holds the current counters). The history is normally only used to see the evolution over time or e.g. for generating graphs. So these are processed at the end of the test. The current counters are of no use here, so it is not necessary to have such a high refresh rate then.
For consistency in method naming we obviously also changed the method call to clear the results. In the old API, we used the method name
In API 2.x, we changed this to
This relates to the frame blasting related objects: Streams and Frames .
The changes are very similar to the changes for Counters of Triggers .
In the old API the counters where returned in key-value lists. e.g. You needed to parse the list before you could retrieve your value
Returns:
NrOfFramesSent 8462 ByteBlower_FrameOid1 4231 ByteBlower_FramOid2 4231
using lrange and foreach {frameOid value} or lindex it was possible to extract that result.
In API 2.x we've changed that to result objects. This allows you to get the value of the counter directly whitout the need of parsing a list. These result object contain also other resultmetrics that help in understanding what you measure e.g. framesizeMin and framesizeMax
In order to retrieve new counters you call the refresh method. Tx.Stream.ResultData is the resultObject from a Tx.Stream.
New in 2.x API are the History Results for Streams and Frames . Each second we create 2 counter snapshots, one Cumulative and one Interval snapshot. Only the last 6 snapshots are kept in memory at server-side and can be requested. These results are usefull to create some statitics over time.
The resulting ResultHistory object contains a 2 lists of stream result objects. One list for the Cumulative snapshots and one containing the Interval snapshots. Each time you refresh this object, it will request up to 6 snapshots for each type from the server and are stored localy. The Clear method on the ResultHistory object will erase the local stored snapshots.
The result history is maintained locally and updated when the Refresh method is called.
By default, the server is configured with a sampling interval duration of 1 second and a sampling buffer length of 6 snapshot. The server maintains the last 6 snapshots of 1 second. So it can buffer the results for 6 seconds. If the server buffer runs full, it will drop the oldest result as a consequence.
When the user obtains the results after the server's buffer became full, the snapshots older than current time minus 6 seconds will be lost. The local history will then have a gap between previous refresh time and current time minus 6 seconds.
As a user, you probably want to have a continuous history of results, without any gaps in time. It is up to the user to make sure that the results are obtained before the buffer of the server runs full.
By default, the refresh interval should be smaller than 6 seconds. Because of timing issues when working at the edge, we advise to keep the refresh interval lower than 5 seconds. The Tcl-HL examples mainly use a refresh interval of 1 second.
A refresh interval less than the sampling interval duration is pretty useless since it will only update the last snapshot in the history (which holds the current counters). The history is normally only used to see the evolution over time or e.g. for generating graphs. So these are processed at the end of the test. The current counters are of no use here, so it is not necessary to have such a high refresh rate then.
For consistency in method naming we obviously also changed the method call to clear the results. In the old API, we used the method name
In API 2.x, we changed this to
The changes are very similar to the changes for Counters of Triggers .
In the old API the counters where returned in key-value lists. e.g. You needed to parse the list before you could retrieve your value
Returns:
RcvNrOfFrames 468 SendNrOfFrames 218 RcvNrOfUndersized 0 RcvNrOfOversized 3 RcvRate 4 SendRate 12
using foreach {name value} or lindex it was possible to extract that result.
In API 2.x we've changed that to result objects. This allows you to get the value of the counter directly whitout the need of parsing a list. These result object contain also other resultmetrics that help in understanding what you measure e.g. framesizeMin and framesizeMax
The Tx counters for a ByteBlowerPort have been dropped. There were generally unused. All relevant tx counters in streams, frames and protocols are now available in their related result objects. Therefore the Tx counters on a ByteBlowerPort have minimal added value.
The counters have further been split up in
In order to retrieve new counters you call the refresh method. ByteBlowerPort.ResultRxData is the resultObject from a ByteBlowerPort's receive counters.
New in 2.x API are the History Results. Each second we create 2 counter snapshots, one Cumulative and one Interval snapshot. Only the last 6 snapshots are kept in memory at server-side and can be requested. These results are usefull to create some statitics over time.
The resulting ResultHistory object contains a 2 lists of ByteBlowerPort result objects. One list for the Cumulative snapshots and one containing the Interval snapshots. Each time you refresh this object, it will request up to 6 snapshots for each type from the server and are stored localy. The Clear method on the ResultHistory object will erase the local stored snapshots.
The result history is maintained locally and updated when the Refresh method is called.
By default, the server is configured with a sampling interval duration of 1 second and a sampling buffer length of 6 snapshot. The server maintains the last 6 snapshots of 1 second. So it can buffer the results for 6 seconds. If the server buffer runs full, it will drop the oldest result as a consequence.
When the user obtains the results after the server's buffer became full, the snapshots older than current time minus 6 seconds will be lost. The local history will then have a gap between previous refresh time and current time minus 6 seconds.
As a user, you probably want to have a continuous history of results, without any gaps in time. It is up to the user to make sure that the results are obtained before the buffer of the server runs full.
By default, the refresh interval should be smaller than 6 seconds. Because of timing issues when working at the edge, we advise to keep the refresh interval lower than 5 seconds. The Tcl-HL examples mainly use a refresh interval of 1 second.
A refresh interval less than the sampling interval duration is pretty useless since it will only update the last snapshot in the history (which holds the current counters). The history is normally only used to see the evolution over time or e.g. for generating graphs. So these are processed at the end of the test. The current counters are of no use here, so it is not necessary to have such a high refresh rate then.
For consistency in method naming we obviously also changed the method call to clear the results. In the old API, we used the method name
In API 2.x, we changed this to
ByteBlower currently supports 3 Congestion Avoidance Algorithms.
In API 1.8.x you could also select serverDefault as CAA. When this was selected, the server would use its default CAA. This changed over releases and thus CAA depended on the version of ByteBlower server software. In 2.x API we've droped this. Now you have to explicitly define your CAA. You need thus to select one of the CAA above and change your code to
To know if a httpsession is still active we had to write something like this.
We had to check the Tcp.Status and decide if the tcp was still active. depending on the returned status values. In 2.x we've simplified this. The client will decide if the Http is done. So you only need to check if the method Layer5.Http.Client::Finished.Get returns True or False
In the 1.x API the counters of a HTTPSession where stored in the SessionInfo object of HTTP.
Like with the triggers we've introduced here also the concept of result objects. These contain the relevant counters in a consistened way. You need to refresh this resultObject to get the new counters. This has as advantage that all the counters are taken on the same moment in time and thus correlate with each other. The names for the different counters are also consistent with those of the Triggers.
Where we had before a mixture of HTTP counters and TCP Counters in our HttpSessionInfoObject
We now have split those up in there separete SessionInfo objects. The Layer5.Http.SessionInfo object has a link to its Layer4.Tcp.SessionInfo object. This new object contains all the information about the underlying TCP session. The counters for this TCPSession are again stored in a result object Layer4.Tcp.ResultSnapshot
We've made the API of IGMP and MLD consistent in methods so it's clear how to use these classes. In the 1.x API, you had to specify the version of the IGMP-session with a parameter.
In the 2.x API we've simplified this API. The method name reflects the version of the session that you will add. In IGMP and in MLD we've used the same syntax for adding a session. This is easier to use and remember.
The complete new API for IGMP can be found here Layer4.Igmp and for MLD here Layer4.Mld}
The frames returned by a Rx.Capture.RawPacket is also placed in a result object. Where Frames.Get returned a nested list of frames, Result.Get returns a list of Rx.Capture.Frame objects. Using the method provided you now can easly retrieve the bytes whitout the need for parsing the list. This was the 1.x way.
In our API2.x this is the prefered way to retrieve the bytes of the first captured frame
