News:

Happy New Year! Yes, the current one, not a previous one; this is a new post, we swear!

Main Menu

.NET Sockets

Started by Punk, October 04, 2009, 08:27:53 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Punk

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?

MyndFyre

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.
Quote from: Joe on January 23, 2011, 11:47:54 PM
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Quote from: Rule on May 26, 2009, 02:02:12 PMOur species really annoys me.

Punk

What would you recommend in my case? (that being a server with many connections)

MyndFyre

Quote from: Punk on October 04, 2009, 09:27:54 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.
Quote from: Joe on January 23, 2011, 11:47:54 PM
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Quote from: Rule on May 26, 2009, 02:02:12 PMOur species really annoys me.

Punk

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


    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.

MyndFyre

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.
Quote from: Joe on January 23, 2011, 11:47:54 PM
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Quote from: Rule on May 26, 2009, 02:02:12 PMOur species really annoys me.

Lead

Quote from: Punk 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


    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)


QuoteSon, 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

Camel

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!