[BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection...

Bob Wyman Bob Wyman" <bobwyman@earthlink.net
Wed, 17 Jan 2001 13:55:35 -0800


This is a multi-part message in MIME format.

------=_NextPart_000_02CA_01C0808D.2A345270
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

One of the things I find very frustrating with a number of network =
protocols is that when you get the "service not available" message, you =
don't get answers to the questions: "Why not?" and "When will it be =
back?." Few protocols allow you to do much more than simply poll the =
darned server from time to time in the hope that the thing will return =
to life. In many cases, that polling can simply make matters worse, =
since the unavailability of the service may be because too many people =
are trying to access it...

It would be very useful, I think, if BXXP could expand it's =
"unavailable" error messages to include:
    1) Service permanently unavailable (i.e. Don't ever try again!)
    2) Service temporarily unavailable (i.e. We'll be back)

This would allow clients to do more rational things in response to being =
rejected. Cases of temporary unavailability include things like startup, =
shutdown, server is overloaded and can't take more connects, databases =
are being reorganized, backups are being performed, etc. These are all =
cases where it would be good to refuse new connections without =
discouraging people from coming back later. Ideally, the protocol would =
support returning an estimated time to availability in the case of a =
temporary shut-out.

It would also, I think, be very useful to provide for a redirection =
response, very much like that which we find in HTTP. I realize that one =
can buy all sorts of fancy gear to do load balancing for you, and I =
realize that once you've got a connection to a BXXP server and start =
talking a profile, that profile could implement redirection, however, it =
is still likely that in many cases, scalability of the solution is going =
to be enhanced by allowing the BXXP servers themselves to communicate =
the need to redirect. Of course, just as with "unavailable" messages, =
redirection should be either permanent or temporary.

        bob wyman


------=_NextPart_000_02CA_01C0808D.2A345270
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>One of the things I find very =
frustrating with a=20
number of network protocols is that when you get the "service not =
available"=20
message, you don't get answers to the questions: "Why not?" and "When =
will it be=20
back?." Few protocols allow you to do much more than simply poll the =
darned=20
server from time to time in the hope that the thing will return to life. =
In many=20
cases, that polling can simply make matters worse, since the =
unavailability of=20
the service may be because too many people are trying to access=20
it...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>It would be very useful, I think, if =
BXXP could=20
expand it's "unavailable" error messages to include:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 1) Service =
permanently=20
unavailable (i.e. Don't ever try again!)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 2) Service =
temporarily=20
unavailable (i.e. We'll be back)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This would allow clients to do more =
rational things=20
in response to being rejected.&nbsp;Cases of temporary unavailability =
include=20
things like&nbsp;startup, shutdown,&nbsp;server is overloaded&nbsp;and =
can't=20
take more connects, databases are being reorganized, backups are being=20
performed, etc. These are all cases where it would be good to refuse new =

connections without discouraging people from coming back later. Ideally, =
the=20
protocol would support returning an estimated time to availability in =
the case=20
of a temporary shut-out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>It would also, I think, be very useful =
to provide=20
for a redirection response, very much like that which we find in HTTP. I =
realize=20
that one can buy all sorts of fancy gear to do load balancing for you, =
and I=20
realize that once you've got a connection to&nbsp;a BXXP server and =
start=20
talking a profile, that profile could implement redirection, however, it =
is=20
still likely that in many cases, scalability of the solution is going to =
be=20
enhanced by allowing the BXXP servers themselves to communicate the need =
to=20
redirect. Of course, just as with "unavailable" messages, redirection =
should be=20
either permanent or temporary.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bob=20
wyman</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_02CA_01C0808D.2A345270--