Networking reliability

[Alex Tweedly]

Scott Slaugh wrote:

>Another issue that seems to pop up occasionally is some network reliability 
>issues. I am using the following script to create a request command. In the 
>requesting computer I put this:
>
>Most of the time the requests make it back and forth without a problem. 
>However, occasionally the requesting computer will just time out without 
>having received a reply. The infuriating thing is that it will do this 
>several times in a row. But as soon as I run the debugger to try and figure 
>out what is going on, it works fine. Incidentally, I use " [EOT]" as an end 
>of transmission string since I sometimes transmit binary data, and seemed to 
>run into problems if I used just a single ASCII character. Have any of you 
>been able to reliably use Revolution as a networked app? Any ideas what 
>might cause these sporadic outages? Is there something I should do to 
>improve my script? Thanks!
>  
>
Some suggestions to help find out better what's going on ....  avoid the 
debugger - to likely to interfere with things.

Can't tell (from what you said) whether the problem is in the
  open connection
  send request
  generate reply
  receive reply

So first thing I'd do is add some logging statements so I can (perhaps) 
tell where the problem is (i.e. the client should log before and after 
each of the open, write, read and close; while the server should log the 
arrival of each request and the reply.)

Possible problems:

it's sometimes considered risky to close the socket immediately after a 
write. I think it *should* be OK, but the truly paranoid avoid doing 
that - leave it to the client to close the socket *after* it has 
received the reply.

it may be that the open is not succeeding; once you have got the 
connection open, the TCP system will protect you losing a packet (which 
does happen in real networks), by re-trying; but if the initial packet 
(or initial return packet) are lost, then you may not succeed in getting 
an open connection.  Best solution - detect the time-out and try again. 
Possibly switch to
"open connection ... with message callBack" to avoid the client being 
stuck while waiting for the reply.

The server currently waits while it sends the reply - it is possible 
(especially if the replies can be large) that it will be held waiting 
for a slow client (or slow/busy connection). While it is held, it might 
be unable to receive or respond to other clients. Should use "write to 
socket ... with message callback"

Not sure if any of those will help - but I'd certainly do the logging 
and avoid the immediate close after write .... and hope one of those 
does it :-)  

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10/05/2005