Winsock Help Needed

[GhostWolf]

I'm in the process of creating an application which will rely on up to five Winsock servers existing on the intranet.

The .Connect function, under TCP, left me with a problem when the client tries to connect and the server's not started, (.State=6). This will be in a fast-paced environment, and I don't want the program spending inordinate amounts of time waiting for the connection to succeed - especially when the target server isn't on-line.

After some research on here, I figure the easiest solution is to have the client transmit a "where-the-heck-are-ya" UDP message, but that leaves me with even more questions:

- With multiple servers available, it seems I'd need to be more specific on the "where are you" message, along the lines of "admin server|where are you"? Or would it be better to have each server monitor a different port for the UDP request?

- Can a server monitor multiple ports under different protocols at the same time, (e.g. port 1007 TCP, and port 1008 UDP)?

So far I've written it to use the TCP protocol, but I've seen mentions that UDP is more efficient. Since the servers won't send responses back to the clients, I'm guessing that may be true. But, that's just guessing, for me.

Any guidance you gurus want to share will be more than welcome.

[dbasnett]

you could turn blocking off and see if you don't get an immediate return. then just check the connection state before using.

[dilettante]

Usually if there is no server (program) listening on a port the server's TCP stack will terminate the connection attempt fairly quickly with a "forcefully rejected" result. If the server (machine) is dead that's another story.

UDP is "more efficient" but only in a relative sense. It can be quicker and lighter but this comes at the expense of potential lost data, no guarantee that datagrams will arrive in sequence, no congestion control, ...the list goes on. If used improperly large data transfers can even be slower than over a TCP connection.

You can handle multiple ports and protocols in one program though.

The Connect event tells the client when its connection has been established. You could easily user a Timer control to time this out earlier if desired, and just close the Winsock control then.

[GhostWolf]

So, I could safely have one socket monitoring a UDP port, (to answer the "where are you" question), and another listening to a TCP port, (for normal processing)? Sounds about perfect, so far...

Fortunately, each packet sent from the clients is only twenty bytes long but, from your example in the other thread, it looks like even that could be split. With 30+ clients connected to the server program, I don't think I like the sound of UDP for normal processing.

[dilettante]

According to its definition, using Winsock (the API underlying the Winsock control) you have to be prepared to reveice just one byte for each DataArrival. Most of the time the bigger issue is falling afoul of another factor, the Nagle Algorithm. This tends to cause "globbing together" of short sequences of bytes more often than short sequences will be fragmented.

Yes, you can use both UDP and TCP. No problem there... until you have two copies of a program or two programs that want to receive the same UDP port data on the same machine. Bind sort of gets in the way.


UDP is fine if used properly. However it has drawbacks to it that TCP exists specifically to handle for you. Routers are also implicitly given the right to drop UDP datagrams whenever they feel busy. Almost all routers will "hold off" and/or temporarily buffer TCP data if they get busy.

If you really care whether a UDP datagram got through or not you have to deal with it yourself. This usually means implementing your own acknowledgement protocol with appropriate timeouts and retry limits. UDP is strictly a "best effort delivery" protocol, where TCP guarantees delivery as long as the connection doesn't break - which usually takes up to 4 minutes even if a cable is unplugged. TCP is very persistent.

[GhostWolf]

Hmmm... The more I read, the less I like UDP even though it seems to me the best bet for a quick 2-byte "are you on-line" query.