VB6: Networking Problems

pcmattman · Post by **pcmattman** » Wed Nov 07, 2007 6:01 pm

Hi everyone,

I'm making a game in VB for a school project and it uses networking for a multiplayer mode. The game itself is working well, with a map system and everything just works. However, I'm having some serious trouble with networking.

For my testing I run the server program and two clients. The two clients connect to the server, and the server sends the MOTD. This works perfectly. The first client receives broadcast packets properly and can see the second client moving. The second client can't receive them properly. I have a chat system implemented, and the second client will only ever receive a broadcast packet after a couple of chat messages have been sent to it. From then on it requires chat messages to "unblock the pipes" and let the broadcast packet through.

The broadcast packet just holds information about a specific player (specified by an ID) to be stored locally until the next broadcast.

Any ideas as to why I'm having trouble with the second client would be great. I've been working at this one bug for about two weeks now and school ends soon.

AJ · Post by AJ » Thu Nov 08, 2007 4:24 am

An idea and a question:

Are the chat messages and packets send on the same port? If so, it may uncomplicate things a bit by having separate ports for separate protocols. Just a thought.

..and the question: Do you have any way of telling if the server is sending out the data to the second client correctly, or is it at the client end?

Cheers,
Adam

pcmattman · Post by **pcmattman** » Thu Nov 08, 2007 4:27 am

Problem is, to have multiple ports would require multiple Winsock controls and a lot more management code (which complicates things further)...

The server, when it is broadcasting, prints to a console. I can see that it is sending to everything properly, it's just the client that isn't receiving it properly.

The thing that really confuses me is why the broadcast packets are only read after a couple of chat messages are sent? Are they in the queue but not read (which I doubt, because VB6 is event based and I do have an event handler for DataArrival), or is something happening elsewhere?

Solar · Post by **Solar** » Thu Nov 08, 2007 4:39 am

Just a wild guess: Is there a cache working somewhere in the pipe? (Which can hold many - small - broadcast packages, but is filled quickly by the - larger - chat messages?)

AJ · Post by AJ » Thu Nov 08, 2007 4:41 am

Another suggestion - are you using UDP? If so, perhaps switching to TCP would be worth it, despite the extra overhead.

Cheers,
Adam

pcmattman · Post by **pcmattman** » Thu Nov 08, 2007 4:42 am

The chat messages are actually the smallest message of them all, so I don't think that can be the cause.

Edit: AJ: I am using TCP.

AJ · Post by AJ » Thu Nov 08, 2007 5:11 am

Sorry for the bitty replies - I'm just putting down thoughts as they come to me. I wrot a network management program years ago in VB5 - but am a little rusty now!

What happens if you disable the chat system for a moment (from the server and client ends)? Does that mean you get the other packets through? I just wonder if you have some kind of logic error rather than a socket error - perhaps you are examining a packet for a control character which isn't coming through when expected or something along those lines? I agree that it would be odd that Client 1 would still be working in that situation, though...hmm...

Combuster · Post by **Combuster** » Thu Nov 08, 2007 9:41 am

Winsock controls suck, use the good ole' interface. With a bit of effort they are better and more bug free than those vb implementations that break half of the time.

That and you can then use setsockopt with TCP_NODELAY to disable nagle's packet merging algorithm. (and other good things like non-blocking read calls)

Speaking of which, I think I just found my IRC bot's nagleing bug

AnonymOS · Post by **AnonymOS** » Thu Nov 08, 2007 5:15 pm

What Service Pack do you have? I remember having a problem using the Winsock control until I installed the latest SP (SP6?), which fixed a bug in it. It was long enough ago that I don't remember the exact situation, but I believe it was similar.