Author Topic: .NET Sockets  (Read 4731 times)

0 Members and 1 Guest are viewing this topic.

Offline Punk

  • Newbie
  • *
  • Posts: 21
    • View Profile
.NET Sockets
« on: October 04, 2009, 08:27:53 pm »
I've looked at documentations on listening sockets but what I don't seem to get is why some examples would use Socket opposed to TcpListner? Aren't they pretty much the same thing?

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: .NET Sockets
« Reply #1 on: October 04, 2009, 09:07:15 pm »
Yes.

It depends on what level of abstraction you'd like.  I believe TcpListener contains a Stream - whereas if you want your Socket to behave in that way you have to implement it yourself.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Punk

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: .NET Sockets
« Reply #2 on: October 04, 2009, 09:27:54 pm »
What would you recommend in my case? (that being a server with many connections)

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: .NET Sockets
« Reply #3 on: October 04, 2009, 11:32:02 pm »
What would you recommend in my case? (that being a server with many connections)

Again, it comes back to a choice about how you want to interact with it.  If you want direct access to the low-level socket - for instance, to be able to call Select() on it - you're probably going to want to use a Socket object directly.  Using a higher-level object will still provide you access to the socket, but you'll have to go through more calls to do it, and you're going to be violating encapsulation.

There will likely only be a minor performance hit by choosing to use the higher-level TcpListener class, so if it makes your life easier, go for it.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Punk

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: .NET Sockets
« Reply #4 on: October 04, 2009, 11:44:27 pm »
As long as using the TcpListener class doesn't hinder performance (nothing major), then it wouldn't be a problem.

The documentation's I've read create a new thread per connection... wouldn't that greatly decrease performance if say.. you have a 400 connections?

For example

Code: [Select]
    Public Sub InitNewClient(ByVal Socket As TcpClient, ByVal clientIPAddress As IPEndPoint)
        clientSocket = Socket
        clientIP = clientIPAddress

        printf("Incoming client " & clientIP.ToString.Split(":")(0), _SOCKET)


        Dim clientThread As Threading.Thread = New Threading.Thread(AddressOf ClientDataArrival)
        clientThread .Start()
    End Sub

The subroutine ClientDataArrival is obviously just a loop that constantly checks the stream.

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: .NET Sockets
« Reply #5 on: October 05, 2009, 04:02:18 am »
TcpListener isn't spawning the thread, though - you are (if you use that code).

One way or another, you're going to need to use another thread to do work with the clients you receive, whether it's a single thread .Select()ing on a lot of sockets, or spawning an individual thread for every client.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline Lead

  • x86
  • Hero Member
  • *****
  • Posts: 635
  • Shaman of Sexy.
    • View Profile
Re: .NET Sockets
« Reply #6 on: October 05, 2009, 06:52:26 am »
As long as using the TcpListener class doesn't hinder performance (nothing major), then it wouldn't be a problem.

The documentation's I've read create a new thread per connection... wouldn't that greatly decrease performance if say.. you have a 400 connections?

For example

Code: [Select]
    Public Sub InitNewClient(ByVal Socket As TcpClient, ByVal clientIPAddress As IPEndPoint)
        clientSocket = Socket
        clientIP = clientIPAddress

        printf("Incoming client " & clientIP.ToString.Split(":")(0), _SOCKET)


        Dim clientThread As Threading.Thread = New Threading.Thread(AddressOf ClientDataArrival)
        clientThread .Start()
    End Sub

The subroutine ClientDataArrival is obviously just a loop that constantly checks the stream.

If I'm not mistaken you can use an asynchronous callback for the DataArrival instead of a loop to check for data constantly. There you WILL take a performance hit if you use a loop like that.

Also Rob, message me on AIM when you have a chance. I have a patch I need to submit for BNCSUtil. (Lockdown)


Quote
Son, if you really want something in this life, you have to work for it. Now quiet! They're about to announce the lottery numbers. - Homer Simpson

Offline Camel

  • Hero Member
  • *****
  • Posts: 1703
    • View Profile
    • BNU Bot
Re: .NET Sockets
« Reply #7 on: October 05, 2009, 12:42:45 pm »
Generally speaking, the ideal server would a few threads -- I'd say about 5, but that number would depend on the type of server you're creating and the target machine you're running on. You don't want a new thread for every connection because the overhead will multiply for every connection, and you don't really need that many threads anyways.

You can also do a single thread. This is much easier to actually write code for, and as a free bonus you never have to worry about synchronization. If your packet handlers are all going to execute very quickly, and especially if your target machine has only a single core, this may be acceptable.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!