Re: [xmlblaster] Mobile application using XMLBlaster via GPRS

[Michele Laghi <michele at laghi.eu>]

Hi Oliver,

Fels, Oliver wrote:
> Hi Michele.
> 
> Thanks for your answers.
> 
>>> The GPRS connection unfortunately is supposed to change IP 
>> addresses 
>>> while moving from cell to cell which might imply problems with the 
>>> xmlBlaster client being logged on with a dedicated address on the 
>>> server. The client will be travelling across a longer 
>> distance (up to
>>> 400km) so cell changes are frequent.
>>>
>> When using the SOCKET Protocol callbacks are tunneled back 
>> through the connection established from the client to the 
>> server. The IP Address of the client is in fact not used by 
>> this protocol, so this should be safe.
> 
> If we are talking about UDP sockets this would be fine I guess.
> However what concerns me is that a TCP socket is still bound to the
> server with its underlying IP address.
> I am wondering if we would have to take precautions if the established
> connection changes its destination address.
> I believe we will have to check this in general.
> 
I was also refering to TCP. Suppose the client leaves the cell. I am not
really sure what happens in such a case but either:
a) the interface is shutdown => IOException => client goes in POLLING
b) the interface hangs => connection ping fails (due to timeout) =>
client goes in POLLING

on the serverside the same thing happens. This means both parts detect
the failure and go in POLLING.

Once the TCP/IP Connection is established in the new cell the Reconnect
succeeds and the client is Online again.

In the case I was describing we were in situation a): that is the
resources where cleaned up immediately. For b) I am not really sure, I
believe it depends on the low level configuration when a timeout would
finally clean up the unused hanging connection on the client side.

>>> 2) Is this a critical issue for the blaster software or is this 
>>> already handled in a way which does not oppose latency problems by 
>>> frequent relogin attempts ?
>>>
>> What probably concerns you is performance: how many clients 
>> do you expect to be simultaneously connected and how often do 
>> you expect them to reconnect ? Once you know this it should 
>> be pretty strightforward to set up a test case simulating 
>> such reconnects.
> 
> We expect a maximum of 200 clients to be continously connected to the
> server at once without logging off.
> As GPRS will be the bottleneck I do not expect much stress on the
> server.
> 
An important parameter is how often these clients are expected to
reconnect, i.e. reconnects/sec on the server. A rough guess is that if
the expected lifetime of such a socket connection is more than 10
Minutes (3 reconnects/sec) it is probably no problem, less must
definitely be tested.

> We will be setting up a testing environment soon however I would like to
> clarify issues before we run into problems.
> 
Great usecase !
Michele

> Thanks,
> 
> Oliver
> 
> 
>