C#

• building a configuration (port, transport, security) driven client/server system
  
• implementing both sync and async client APIs
  
• adding hooks (e.g. custom compression) before data is sent/received
  
• implementing logging and instrumenting traffic
  
• implementing handshaking (full-duplex) communication and transacted communication
  
• embedding the server in any type of host host (GUI app, console app, web app, Windows service)

• WCF Introduction - Part1[^] (CP) <-- recommended
  
• WCF Getting Started[^] (MSDN)

Chesnokov Yuriy wrote:

I've seen those samples with a server getting back data from a client, sending back response and closing it.

I'm intrested in a server handing many clients connected and client connected to many servers architecture.

Chesnokov Yuriy wrote:

There should be some ready described solutions to avoid common mistakes.

Bastard Programmer from Hell

class Employee 
        {
            public void Talk()
            {
                MessageBox.Show("I am an Employee.");
            }
        }

        class ContractEmployee: Employee 
        {
            public void ContractTalk()
            {
                MessageBox.Show("I am a Contract Employee.");
            }
        }

static void CreateEmployee()
        {
            Employee e = new ContractEmployee();
            e.Talk();
            e.ContractTalk();
        }

interface IEmployee
        {
            void Talk();
        }

        abstract class Employee : IEmployee
        {
            public abstract void Talk();
        }

        class PermanentEmployee:Employee
        {
            public override void Talk()
            {
                MessageBox.Show("I am a Permanent Employee.");
            }
        }

        class ContractEmployee: Employee 
        {
            public override void Talk()
            {
                MessageBox.Show("I am a Contract Employee.");
            }
        }

static void CreateEmployee()
        {
            Employee e = new ContractEmployee();
            e.Talk();
            e = new PermanentEmployee();
            e.Talk();
        }

class Employee { }

class ContractEmployee : Employee { }

class CastExample2
{

    public static void Main ()
    {
        ContractEmployee ce = new Employee(); // Won't compile.
    }
}

nstk wrote:

And this is ok for me, but still I do not understand why is such a declaration useful and what it actually means. If I declare

Employee e = new ContractEmployee()

and e has the properties of the Employee class, why then not write

Employee e = new Employee()

as we "normally" do? What is the difference between those two?

MicroVirus wrote:

The difference between the two lines is that in the first, e behaves like a ContractEmployee and in the second e behaves like an Employee.

abstract class Animal {
 public abstract string Noise { get; }
 public virtual string Feed() { return "Mm, tasty."; }
}

class Dog : Animal {
 public override string Noise { get { return "Woof."} }
 public void GiveBone() { Console.WriteLine("Chomp."); }
}

class Cow : Animal {
 public override string Noise { get { return "Moo."; } }
 public override string Feed() { return "I'll only eat it if it's green."; }
}

void FeedAndListen(Animal animal){
 Console.WriteLine(animal.Feed());
 Console.WriteLine(animal.Noise);
 // You can't do this, because the animal type is not known
 // animal.GiveBone();
}

static void Main(){
 List<Animal> animals = new List<Animal>();
 animals.Add(new Dog());
 animals.Add(new Cow());
 foreach(Animal animal in animals) FeedAndListen(animal);
}

BobJanova wrote:

Code which does not know about ContractEmployee can still call methods on it if they are overrides of virtual (or abstract or interface-defined) methods of a base class.