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

Marshall T. Rose mrose+mtr.netnews@dbc.mtview.ca.us
Wed, 17 Jan 2001 20:28:56 -0800


This is a multi-part message in MIME format.

------=_NextPart_000_0040_01C080C4.1D864CE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

hi. in terms of unavailable messages:

421 is a transient problem
521 is a permanent problem

in terms of redirects:

i can see arguments for returning a redirect instead of a greeting. i can
also see arguments for returning a redirect in response to a start. i'm more
inclined to favor the latter since a peer might offer several services, but
need to do redirects on only a subset of them. supporting either of these
approaches requires a change to the protocol. that's not fatal, since
there's a field in the greeting element that we can use to signal
extensibility. however, until the beep specs get published, it doesn't make
much sense to talk about more enhancements...

/mtr
  ----- Original Message -----
  From: Bob Wyman
  To: bxxpwg@lists.invisibleworlds.com
  Sent: Wednesday, January 17, 2001 13:55
  Subject: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not
available), and redirection...


  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_0040_01C080C4.1D864CE0
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.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>hi. in terms of unavailable messages:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>421 is a transient problem</FONT></DIV>
<DIV><FONT size=3D2>521 is a permanent problem</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>in terms of redirects:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>i can see arguments for returning a redirect instead =
of a=20
greeting. i can also see arguments for returning a redirect in response =
to a=20
start. i'm more inclined to favor the latter since a peer might offer =
several=20
services, but need to do redirects on only a subset of them. supporting =
either=20
of these approaches requires a change to the protocol. that's not fatal, =
since=20
there's a field in the greeting element that we can use to signal =
extensibility.=20
however, until the beep specs get published, it doesn't make much sense =
to talk=20
about more enhancements...</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>/mtr</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dbobwyman@earthlink.net =
href=3D"mailto:bobwyman@earthlink.net">Bob=20
  Wyman</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=3Dbxxpwg@lists.invisibleworlds.com=20
  =
href=3D"mailto:bxxpwg@lists.invisibleworlds.com">bxxpwg@lists.invisiblewo=
rlds.com</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, January 17, =
2001=20
  13:55</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [BXXPwg] Why won't you =
talk to=20
  me? (i.e. 421 - service not available), and redirection...</DIV>
  <DIV><BR></DIV>
  <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=20
  be 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=20
  many cases, that polling can simply make matters worse, since the=20
  unavailability of the service may be because too many people are =
trying to=20
  access 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=20
  things in response to being rejected.&nbsp;Cases of temporary =
unavailability=20
  include things like&nbsp;startup, shutdown,&nbsp;server is =
overloaded&nbsp;and=20
  can't 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=20
  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=20
  realize that one can buy all sorts of fancy gear to do load balancing =
for you,=20
  and I realize that once you've got a connection to&nbsp;a BXXP server =
and=20
  start talking a profile, that profile could implement redirection, =
however, it=20
  is 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=20
  be 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></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0040_01C080C4.1D864CE0--