TCPIP vs UDP effect on LAN

[tedsmith]

If I had a server feeding 100 bytes of data say once every 3 minutes to 1000 clients, which one of the following methods would put the lowest load on a 1ghz LAN?
1. TCPIP: Opening a Winsock connection in turn to each client, send data then Close.
2, TCPIP: Opening a number (say 60) of Winsock ports at a time and do as above.
3. UDP: OPen for broadcasting, broadcast data in one big string separated by an ID so each Client only recognises it's own data then closing connection.
4.UDP: Keep open for broadcasting, broadcast data with an ID so each client sees but only captures it's own data.
5. Any other method.
Thanks in advance

 

[dilettante]

Why not turn this around so the clients connect to the server and then keep these connections open? It solves all kinds of problems and presents little load to the network compared to repeatedly re-establishing new connections. The biggest cost will be the non-paged pool memory eaten up on the central server of course.

An improvement on that would be to use Named Pipes which will leverage any existing UDP and TCP channels Microsoft Networking is already maintaining between machines on the LAN. The downside is we don't have anything as handy as the Winsock control and must resort to using API calls, but they aren't too bad.

Any UDP-based solution has to be tolerant of lost and out of sequence datagrams of course. That or you implement a bunch of protocol logic on top of UDP to detect lost data and retry it, buffer and sequence the data, etc. I find most programmers using UDP ignore this, and when their data gets lost and programs lock up they just curse Microsoft (for their own incompetence).

If your application can tolerate lost data though UDP broadcasts (even more lossy than point to point UDP) can be an answer. But if you can use UDP broadcasts you can once again lighten the load by using Mailslots, which also use the Microsoft Networking infrastructure instead of tying up additional UDP ports. Mailslots are like UDP in that you can send point to point or send broadcasts, since Mailslots are connectionless.

Named Pipes and Mailslots don't even require a TCP/IP network, though NetBEUI and IPX networks are pretty rare today.

In .Net it was discovered that their inefficient Web Service and .Net Remoting infrastructure was in even worse shape because these relied on HTTP and TCP. By .Net 2.0 the ability to use Named Pipes, Maislots, and DCOM "under the covers" was added in an attempt to reduce the overhead of distributed component coupling. WCF took this approach even further.

This brings me to the last suggestion I have: DCOM. Your application bears a striking resemblance to the classic Coffee Monitor example in the VB6 manuals.

Using DCOM may radically simplify your client logic, using either events or callbacks to signal information back from the server. Since this also leverages Microsoft Networking the network and server memory overhead are reduced too as long as you are careful about parameter marshalling (pass anything you can ByVal).

DCOM is the "native" way you do this sort of thing in VB6. I'm sort of amazed this wasn't your first choice.

How To Troubleshoot DCOM for Visual Basic Client/Server Applications contains a great deal of useful information, as well as links to a number of articles on the fundamentals of creating DCOM applications in VB6.

 

[tedsmith]

Thanks
I had never heard of DCOM or the coffee monitor example.
My help disk says that DCOM is distributed with NT4 SDK
Is it also on 2000 or XP or can I get it separately?

 

[dilettante]

They might be talking about DCOM Config utilities. DCOM was an add-on to Win95/98 and NT 4.0 but was standard by Win98SE and Win2K and was rollied into Component Services with COM+ at some point in Win2K's life cycle.

If you try Start|Run and enter DCOMCNFG the configuration utility should run. I just take it for granted these days, but I also don't support anything older than Win2K anymore.

This was the core of what used to be called "Windows DNA" prior to the .Net venture. It is pretty much how client/server programming in VB6 was meant to be done, though that was before the Internet boom peaked.


You see more here on the use of Winsock and TCP/IP now because there is less professional in-house VB6 programming going on anymore. Most who remain are doing smaller scale two-tiered applications that are simple front ends to a database. This has tended to skew the topic toward Internet oriented programming, where DCOM is not useful.


So I guess what I'm suggesting is that if you don't already have an investment in DCOM skills you might be better off with TCP or UDP. There is a learning curve to DCOM programming, deployment, and security and you don't find as much tutorial material on n-tier VB6 LAN development anymore.

Do you have any reason to think the "obvious" path results in excessive network loading? By that I mean simply opening each TCP connection, sending your 100 bytes, and closing each connection. It's a lot of traffic, sure, but how much is too much?

 

[tedsmith]

Problem is I don't know if it will be excessive or not.

This proposed idea of mine involves a city wide network with various legs of different speeds (and used for other things)

What I was asking is what method that would put the least load on the network.

Then you can do no better and it is in the customers decision whether they have to improve their network or not if they want the facility.

 

[dilettante]

If you are talking about any kind of WAN then this immediately suggests sticking to TCP/IP. A WAN rules out the other things I mentioned, which are sub-optimal to unworkable outside of LANs because they require full network transparency.

For the same reason you might find that UDP is out, or at least any kind of UDP broadcasting. Forget multicasting because it is pretty much impractical in VB6 without the aid of additional software.

The lowest network load that is going to work will be unicast UDP datagrams. But remember that UDP does not guarantee delivery or sequence.

For TCP the lowest loading is presented by persistent TCP connections. It is reliable because TCP will retry any packets dropped by routers and network cards, and it buffers incoming data and sequences it so the application always gets everything in the order sent.

Note that "reliable" in this case does not mean that connections can't be broken and require re-establishment though! Reliable means that data will not be lost erratically, unlike UDP datagrams. Remember that routers and network adapters are allowed to drop packets whenever they are too busy, and so they do.

Using a new connection for each transmission presents the most overhead because a certain amount of chatter is required to establish and close connections. This also adds some latency and more processor overhead on the central server, but may save on non-paged memory resources at the server.

Connecting from the server to the clients however may lead to exhaustion of the ephemeral port pool. Your server is really acting as a client in TCP terms. But since your messaging frequency is only once per 3 minutes and the TIME-WAIT delay is 4 minutes this should not be a problem. By the time you need to connect to a "client" the third time, the first ephemeral port will have timed out and be available once again.

 

[tedsmith]

Thanks for the advice.
I have noticed that there is normally no network traffic when open TCP channels are not transmitting any data. You can pull out a plug and poke it back within 60 seconds and the connection remains open on my local network.

As the server will always be initiating the data transfers, it looks like a continuously open system TCP would be the best with timeouts to reconnect if the connection is broken.

All the clients are unattended data gatherers and indicators.

The client will send back an acknowledge of a correct checksum so there would be no problem if a packet or two are missed.

I have put in a few systems like this with 20 clients but never attempted 500 yet!

 

[dilettante]

Yes, TCP is designed to be resilient in the face of network interruptions. Remember, a TCP "connection" is a software concept, and nothing physical at all.