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. > > 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. We will be setting up a testing environment soon however I would like to clarify issues before we run into problems. Thanks, Oliver
