[an error occurred while processing this directive]

system choose one for me on the connect() call? Should I bind()

  From Andrew Gierth (andrew@erlenstar.demon.co.uk):

  ** Let the system choose your client's port number **

  The exception to this, is if the server has been written to be picky
  about what client ports it will allow connections from. Rlogind and
  rshd are the classic examples. This is usually part of a Unix-specific
  (and rather weak) authentication scheme; the intent is that the server
  allows connections only from processes with root privilege. (The
  weakness in the scheme is that many O/Ss (e.g. MS-DOS) allow anyone to
  bind any port.)

  The rresvport() routine exists to help out clients that are using this
  scheme. It basically does the equivalent of socket() + bind(),
  choosing a port number in the range 512..1023.

  If the server is not fussy about the client's port number, then don't
  try and assign it yourself in the client, just let connect() pick it
  for you.

  If, in a client, you use the naive scheme of starting at a fixed port
  number and calling bind() on consecutive values until it works, then
  you buy yourself a whole lot of trouble:

  The problem is if the server end of your connection does an active
  close.  (E.G. client sends 'QUIT' command to server, server responds
  by closing the connection). That leaves the client end of the
  connection in CLOSED state, and the server end in TIME_WAIT state. So
  after the client exits, there is no trace of the connection on the
  client end.

  Now run the client again. It will pick the same port number, since as
  far as it can see, it's free. But as soon as it calls connect(), the
  server finds that you are trying to duplicate an existing connection
  (although one in TIME_WAIT). It is perfectly entitled to refuse to do
  this, so you get, I suspect, ECONNREFUSED from connect(). (Some
  systems may sometimes allow the connection anyway, but you can't rely
  on it.)

  This problem is especially dangerous because it doesn't show up unless
  the client and server are on different machines. (If they are the same
  machine, then the client won't pick the same port number as before).
  So you can get bitten well into the development cycle (if you do what
  I suspect most people do, and test client & server on the same box

  Even if your protocol has the client closing first, there are still
  ways to produce this problem (e.g. kill the server).

[an error occurred while processing this directive]