Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

As I understood, via this interface I can run multiple requests and organize something like parallel download? How I can do it at practice? Where is described all sides of this interface and IWebReq structure?

Please, help!

As I understood, via this interface I can run multiple requests and organize something like parallel download? How I can do it at practice? Where is described all sides of this interface and IWebReq structure?
Please, help!

As I understood, via this interface I can run multiple requests and organize something like parallel download? How I can do it at practice? Where is described all sides of this interface and IWebReq structure?
Please, help!

mohlendo, sorry, but this documet tells nothing about IWebEng :mad:

mohlendo, sorry, but this documet tells nothing about IWebEng :mad:

IWebEng is an abstract base class. You would need to take care of the implementation yourself.

IWebEng is an abstract base class. You would need to take care of the implementation yourself.

Are you trying to start and maintain multiple HTTP requests simultaneously, if so why do you need to have custom implementation of IWEBENG, you could create IWEB instance for each of the HTTP request, maximum number is limited by the number of TCP/IP socket available in the handset.

Are you trying to start and maintain multiple HTTP requests simultaneously, if so why do you need to have custom implementation of IWEBENG, you could create IWEB instance for each of the HTTP request, maximum number is limited by the number of TCP/IP socket available in the handset.

ruben wrote:Are you trying to start and maintain multiple HTTP requests simultaneously, if so why do you need to have custom implementation of IWEBENG, you could create IWEB instance for each of the HTTP request, maximum number is limited by the number of TCP/IP socket available in the handset.
Well, it should be the best variant, but not. In the practice, when we have 2 instances of IWeb(or more), they fails every time... Maybe, I've missed something...
Someone met similar problem?

ruben wrote:Are you trying to start and maintain multiple HTTP requests simultaneously, if so why do you need to have custom implementation of IWEBENG, you could create IWEB instance for each of the HTTP request, maximum number is limited by the number of TCP/IP socket available in the handset.
Well, it should be the best variant, but not. In the practice, when we have 2 instances of IWeb(or more), they fails every time... Maybe, I've missed something...
Someone met similar problem?

In the documentation for IWEB_GetResponse()
states (in part):
"A good way to make sure you don't violate any of these rules is to keep
and use a *single* IWeb pointer for the lifetime of your application.
This simplifies and thus bulletproofs your interaction with IWeb and its
callbacks and allows IWeb to do HTTP Keep-Alives properly."
So it would seem preferable to keep a single IWeb instance whenever possible.
To download multiple contents simultaneously, simply issue multiple IWEB_GetResponse() calls.
There is no requirement to wait for one transaction to finish before starting the next transaction.
There is a WebOpt to limit the number of simultaneous transactions which can be active; the option name is WEBOPT_ACTIVEXACTIONS and the value is an unsigned integer scalar. If this WebOpt is set, any transactions which are submitted beyond the limit are queued only, and not started until older transactions have finished.
Tony
BREW Support

In the documentation for IWEB_GetResponse()
states (in part):
"A good way to make sure you don't violate any of these rules is to keep
and use a *single* IWeb pointer for the lifetime of your application.
This simplifies and thus bulletproofs your interaction with IWeb and its
callbacks and allows IWeb to do HTTP Keep-Alives properly."
So it would seem preferable to keep a single IWeb instance whenever possible.
To download multiple contents simultaneously, simply issue multiple IWEB_GetResponse() calls.
There is no requirement to wait for one transaction to finish before starting the next transaction.
There is a WebOpt to limit the number of simultaneous transactions which can be active; the option name is WEBOPT_ACTIVEXACTIONS and the value is an unsigned integer scalar. If this WebOpt is set, any transactions which are submitted beyond the limit are queued only, and not started until older transactions have finished.
Tony
BREW Support