[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Mobile application using XMLBlaster via GPRS
Fels, Oliver wrote:
> Hi Michele.
> Thanks for your answers.
>>> The GPRS connection unfortunately is supposed to change IP
>>> 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
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 !