私がサーバー側の開発者としてすべてを制御できるようにするために、サーバーの最初のバージョンは、Microsoftの記事で説明されているように、System.Net.Sockets.Socketクラスを使用して作成されました。ソケットはBegin / Endメソッドで（原則として、WCFを除いて、Microsoftからさらにリストされている他のすべてのテクノロジーと同様に）機能するため、イベントベースのモデルで機能する機能を提供する小さなラッパーが作成されました。これが最初のステップであり、クライアントとサーバーは正常に機能しました。
すぐにSSLが必要になったため、OSIモデルの上位レベルに移動し、SSLがねじ込まれたSystem.Net.Sockets.TcpListenerクラスを使用してサーバー側を書き直す必要がありました。これらはステップ2と2.5で、クライアントとサーバーは正常に機能し、クライアントを書き直す必要さえありませんでした。パケットの傍受により、すべてが正常で、何も変更されていないことが示されました。
後で、すべてのベルとホイッスルを備えた本格的なHTTPSが必要になりました。このために、サーバーは再び書き直されました。現在はSystem.Net.HttpListenerクラスを使用しています。これらはステップ3と3半であり、ここでもすべてがうまく機能し、クライアントをやり直す必要はありません。公平を期すために、カスタムモバイルクライアントに加えて、テストC＃クライアントと一連のテストもありましたが、コストをかけて書き直す必要があったことに注意してください。
4番目のステップは、システムをすべての方向にスケーリングし始めたときに始まり、独自のラッパーがプロジェクトのボトルネックになりました。それから私はWCFについて読み、ある夜（まあ、ほとんど）に私は全体の相互作用を書き直しました。クライアント側（および転送されるパケット）では、すべてが同じままですが、サーバー側のコードは、半ダースの深刻なクラスからわずか数行に削減されています。
この話には2つの教訓があります。
- （明らかに）自転車を発明することは悪いことです。すぐにGoogleにアクセスして、新しいテクノロジーを自分で使用することを恐れなかった場合、サーバー開発を約3分の1に減らすことができます。
- （そしてこれが主なことです）異なるツールを使用して同じメカニズムを実装するタスクは、トピックの深い理解を達成することを可能にする最良の学習方法です。何かを数回するだけで、それを覚えています。しかし、同時に使用するツールを複雑にする（変更する）と、スキルが大幅に向上します。