やり取りされるものはオブジェクトですが、ソケットという側面から、固有の 問題が出てきます。KONOEのプロセスはネットワーク上の任意のところにある わけですから、それらの指定が必要になります。
UNIXのTCPやUDPのソケットはクライアント・サーバのモデルに基づいて実装 されています。サーバは特定のポートを接続要求の受け取り口に設定して 要求を受け付けます。そういったポート番号の管理も必要です。
実際のオブジェクト転送の場合、相手先が受け取れる状態であるかどうかと いう問題があります。基本的に送信要求はその転送が完了してから呼出し先に 制御が戻ることになりますが、オンラインシステムではそこでハングアップ しないように、とりあえず送信要求を実行待ち行列(キュー)に登録して、制御は 呼び出し元に戻すけれども、転送そのものはその後に非同期で行なわれる ことが必要になることもあります。このようなキューやバッファの実装も 課題になります。
同じ計算機の間のソケットでは、例えば共有メモリーを用いたデータの シェアが可能です。ネットワーク通信では実際にソケット通信をおこなう 必要があります。このへんを隠蔽したいわけです。
転送要求が完全に実行されるまではもとのデータは保持されなければ なりません。いつの段階で転送オブジェクトが破棄可能になるかを 的確に呼び手に伝える方法を考える必要があります。もしくは、メモリーは 転送終了と同時にdeleteされて、システムに返されるような実装も可能です。
直前の転送要求が完了するまでに、次の転送要求は受け付けられるように 作られなければなりません。実行待ち行列を内蔵することが要求されています。