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 > > >
