Network programming in C#, Network Programming in VB.NET, Network Programming in .NET
Available now!
Buy at Amazon US or
Buy at Amazon UK



Articles

» Windows API reference
» Webcam streaming in VB.NET
» Remoting with firewalls
» RSA from first principles
» Key & MouseLogger in .NET
» Networking Resource Kit for .NET
» Migrating VB6 Winsock to VB.NET
» Migrating C++ sockets to C#
» RFC Reference guide
» COM Reference guide
» WMI Reference guide
» SQL stored procedures
» TCP & UDP port reference
» NET Framework reference
» Ethernet Type codes
» MAC address assignments
» DLL entry point reference
» Boost SQL performance
» Free SMS UK
» Free SMS Ireland
» Free SMS South Africa
» Internet Explorer

Contact us

Migrating C/C++ Network code to C#

.NET is able to leverage the same Winsock API functions as C/C++ code, and it is equally able to utilize the Winsock ActiveX control, which may be used in some Visual C++ applications, however, it has itís own native socket handling mechanisms, which are much simpler to use and offers better performance.

The native .NET socket programming models fall broadly into two categories, asynchronous and synchronous. Both of these models, are explained fully, and with ample source code in the book Network Programming in .NET (Buy at Amazon UK) (Buy at Amazon US) .

Again, it cannot be stressed enough, Do not use the Winsock API in .NET, it will greatly overcomplicate your application, for no benefit.

C/C++ Network code can fall into a large range of possible models, it is important to recognize which model your application uses, so that when migrating the application to C# (or VB.NET) you can tell which .NET socket model most closely matches your design.

The main models are:

  • Blocking Model
  • Select Model
  • Windows Message Model
  • Event Model
  • Overlapped I/O Model
  • Completion port Model

Blocking Model

The blocking model in C/C++ is the simplest technique to use, and is virtually identical in performance characteristics as the Synchronous Model in .NET.

However it is not very scalable, and offers the lowest performance of all models.

A blocking model server, after accepting a client would follow these steps

  • Create a new Thread
  • In this thread:
    • Call Recv (blocking)
    • Optionally create a new thread to process the data
    • Repeat step 1 until data is exhausted.

Usually found in: Prototype code, non-production applications.

For this model: Easy to understand, and use

Against this model: Every client consumes a thread, thus there would be a significant performance hit due to thread switching.

Select model

This model has its roots in UNIX network code, and it has been preserved to help interoperability between Windows C, and UNIX C code. It does not offer very good performance, due to the required polling structure, However, it is more similar to .NETís asynchronous model than the previous model.

A select model server, after accepting a client would follow these steps

  • Add a socket to the read set using FD_SET
  • Call Select
  • Loop through all sockets in the set calling FD_ISSET
  • If FD_ISSET returns true, call Recv on the socket.
  • Repeat until data is exhausted

Usually found in: Code derived from legacy UNIX applications

For this model: Possible to multiplex connections and I/O on many connections from one thread, up to a maximum of 1024 (not guaranteed)

Against this model: Substantial performance losses due to polling and socket creation with large socket sets.

Windows Message Model

This model was one of the simpler models to use when developers used to be expected to handle the windows message loop (winProc) for their application. Nowadays, in modern languages such as C# or VB.NET, the underlying windows forms architecture handles this for you. The cSocket object in MFC actually uses this technique Ė Anyway, in this model, events are passed back to the application as windows messages. Again, its closest relative is the .NET asynchronous model.

A windows message model server, after accepting a client would follow these steps

  • Call WSAStartup
  • Bind the socket
  • Call WSAAsyncSelect

In the message loop, where a WM_SOCKET message was detected:

  • Call WSAGETSELECTEVENT(lParam)
  • If this matches FD_READ then call Recv

Usually found in: Client network applications with a windows GUI

For this model: Efficient detection of network events.

Against this model: Cannot Read & Write simultaneously from the same thread.

Event Model

The event model is similar to the windows message model, but it does not use the windows message loop, so therefore can be used in applications without a user interface. It is closest to .NETís asynchronous model

An event model server, after accepting a client would follow these steps

  • Call WSACreateEvent
  • Binds the socket
  • Call WSAEventSelect
  • Call WSAWaitForMultipleEvents
  • For each event Ė
    • Call WSAEnumNetworkEvnts
    • Check if _WSANETWORKEVENTS.lNetworkEvents masks FD_READ
    • If so, call Recv

Usually found in: Windows 9x network applications with no user interface

Pros: No polling required, up to 64 sockets per thread.

Cons: Canít read and write simultaneously from the same thread

Cons: Uses user supplied buffers rather than system buffers, meaning that data needs to be copied prior to processing.

Overlapped I/O Model

The overlapped I/O Model is new to Winsock 2.0, and is thus is best suited to Windows 2000, NT 4, XP and Longhorn. It has higher performance than the previous stated methods, but is also more complex. Note: The ReadFile and WriteFile methods can be used to simulate Overlapped I/O with Winsock 1.1 in Windows NT, but this should not be used for compatibility reasons. It maps most closely to the asynchronous model in .NET.

An overlapped I/O model server, after accepting a client would follow these steps:

  • Call WSACreateEvent
  • Bind socket
  • Call WSARecv (non blocking)
  • Call WSAWairForMultipleEvents (blocking)
  • Call WSAResetEvent
  • Call WSAGetOverlappedResult
  • Process data
  • Repeat from WSARecv

Usually found in: High performance clients on Windows NT / 2000

Pros: Can Read & Write simultaneously in the same thread

Pros: Uses internal system buffers for added performance

Cons: Limited to 64 events

I/O Completion port Model

The I/O completion port model offers the best performance, and, in fact, this is what .NET uses Ďunder the hoodí, to provide itís asynchronous model

An I/O Completion port server, after accepting a client would follow these steps:

  • Bind socket
  • Call WSARecv (non-blocking)
  • Call WSAWairForMultipleEvents (blocking)

In the call back function

  • Process data
  • Call WSARecv

Usually found in: High performance servers.

Pros: Can Read & Write simultaneously on the same socket

Pros: Uses internal system buffer for added performance

Pros: Callback is invoked from underlying system for instant event notification

Cons: Limited to 64 events




Google

Copyright 2014 Open Merchant Account Ltd.