補足ですが、
ソケットはTCPソケットを想定しています。

> 起動時にconnectして終了時にcloseするような設計をすべきでしょうか？
> それとも毎回の通知においてConnect、Closeを行うべきでしょうか？

case-by-case.
とはいえ1000本のsocketを始終繋ぎっぱてのも問題。

# connectせずに「UDPで投げっぱなし」という選択はアリですか?
# 確実に相手に届く保証はありませんけど。

ありがとうございます。

もともとudpがいいのでは？と考えていましたが
重要な通知もありますので、
tcpで行わざるを得ません。

１０００本のソケットつなぎっぱは問題ですよねえ。
やはり・・・

基本は端末からは
１）サーバへconnect
２）サーバへwrite
３）サーバへClose
って動きになるのでしょうか？

大半の通知は端末側は通知した後のサーバの処理結果を知らなくてもいいです。
一部だけ、知らないといけない通知もありますが、
それは
１）サーバへconnect
２）サーバへwrite
３）サーバへselect
４) サーバよりread
５）サーバへClose
って動きになるのでしょうか？

サーバはマルチスレッドを想定していますが
子プロセスとマルチスレッドは同義語ですか？

手順はそんなところでしょうね。

> サーバはマルチスレッドを想定していますが
> 子プロセスとマルチスレッドは同義語ですか？

違います。
プロセスは実行モジュール(exe)が別。
スレッドはサーバ内の１関数です。

ありがとうございます。

さて、ソケットサーバが一つ端末からの接続で占有されないためには
ACCEPT後子プロセスを作成するのが一般的な方法ですか？

下記のサイトで勉強していますが・・・

http://hp.vector.co.jp/authors/VA003991/kouza/senior/kouza_socket.html

よろしくお願いします。

> さて、ソケットサーバが一つ端末からの接続で占有されないためには
> ACCEPT後子プロセスを作成するのが一般的な方法ですか？

'一般的'とは如何なる意味ですか?

実装次第でどうにでもできます。
スレッドでもプロセスでもselect待ちでも。