HarmonyOS development: Far Field communication service rcp session problem

Foreword

this paper is based on api13.

Before, I opened up a rcp-based, that is, based on the network library of Remote Communication Kit (far field Communication Service) had no problems during testing, but after open source, many problems were exposed, such as the wrong type of post request, the problem of not being able to request after many requests, the problem of header not being able to be obtained in the interceptor, etc. These problems are mainly caused by not carefully checking official documents and not fully self-testing, in order to avoid making mistakes in the future, I simply record these problems one by one, hoping to help some friends.

Question

after the package was completed at the beginning, I also did some tests. After there was no problem, I opened the source. However, after some time, I received a strange problem, saying that the packaged network library could not request the problem after making many requests.

At that time, I was all different. I couldn't ask what the problem was. Why did I report such a problem after many requests? With this question in mind, I ran my Demo and started testing.

Whether it is a get request, a post request, or other request methods, I have tested it. After trying many times, I found no problem. The requests are normal and the data can be returned normally. Is this young man playing with me?

It is unlikely that who will play tricks with questions. Besides, those who can ask questions are absolutely loyal fans. But why can't I reproduce his questions? Maybe I didn't ask enough?

So, I started to request again and again, staring at the log console, once, twice, until the 17th time, the result did not return, also did not report the error, at this time, I was surprised to find that there was indeed this problem, almost wronged the good man.

No, I packaged them according to official cases. Is it an official Problem? So I checked the official documents again, found a case casually and ran it.

The interface will not be written here, just find an interface.

private tempNumber: number = 0
private doHttp() {
//Define session Config object
const sessionConfig: rcp.SessionConfiguration = {
requestConfiguration: {
transfer: {
autoRedirect: true,
timeout: {
connectMs: 10000,
transferMs: 10000
}
},
tracing: {
verbose: true
}
}
}
//Create a communication session object
const session = rcp.createSession(sessionConfig)
//Define request object rep
let req = new rcp.Request('xxx', 'GET')
//Initiate a request
this.tempNumber++
session.fetch(req).then((response) => {
Console.log ("===th"+this. textNumber+"second request:"+response. toString())
}).catch((err: BusinessError) => {
console.log("=======ERROR:" + err.message)
})
}

After running, the above problems will indeed occur. After checking the log console, it is found that more than 16 times, the following abnormal error message will be directly displayed:

I can't analyze this either. When I was about to give the official work order, an explanation came into view, rcp can only create 16 session instances, that's why the first 16 requests were okay.

How to solve

what? Only 16 requests can be initiated, which is obviously unreasonable. There are more than 16 requests for a project. Looking back at the official case carefully, it seems that the initiation of the Request is not through the session, but through the Request in the end. It seems that I misunderstood the official, which is very embarrassing.

The solution is also very simple, that is, to reuse the session and provide the function of re-creating the session, so that the problem caused by creating the session more than 16 times can be solved.

Or the above code case, we simply do the following processing:

private tempNumber: number = 0
private mSession?: rcp.Session = undefined

  private doHttp() {
    const sessionConfig: rcp.SessionConfiguration = {
      requestConfiguration: {
        transfer: {
          autoRedirect: true,
          timeout: {
            connectMs: 10000,
            transferMs: 10000
          }
        },
        tracing: {
          verbose: true
        }
      }
    }

    if (this.mSession == undefined) {
      this.mSession = rcp.createSession(sessionConfig)
    }

    let req = new rcp.Request('xxx', 'GET')

    this.tempNumber++
    this.mSession.fetch(req).then((response) => {
      console.log("===" + this.tempNumber + ":" + response.toString())
    }).catch((err: BusinessError) => {
      console.log("=======ERROR:" + err.message)
    })

  }

as you can see, there will be no more than 16 problems.

Precautions

in the actual network library encapsulation, we cannot deal with it in a simple way. After all, there are many issues to consider, for example, what should I do if I need to recreate the session? The session has been recreated. How to ensure that some requests use the first session and some requests use the second session must be considered.

It is recommended to store the currently created sessions in the form of map collection and identify a unique key for each new session, so that the request can be distinguished from the specified session problem.

As for whether you want to recreate the session, just pass the parameter.

Related Summary

generally speaking, the problem is not very big, and it is not very troublesome to solve it. Therefore, in the actual development, it is recommended to read more about some official documents, so as to avoid unnecessary troubles in the follow-up in advance.

There is also a more resource-consuming way to solve this problem, that is, after each request, the session is closed directly, but there will be N requests in a project, and each request must be closed......, Of course it measures itself.