Ok so I have gotten my program as far as connecting to a server, sending a username and password, having the server check for the account and its status (banned or approved) and logging in or being rejected for either a non existing account or a banned account and then program not going further unless its an ok login. Im at the auto patcher screen. I know what I need to do some what to make an auto patcher, but I dont know how I can send files through winsock. Can anyone direct me to any resources that would teach this, or teach me though these forums? That would be great! Regards, Nathan Krygier

here is your answer

http://www.google.ca/search?hl=en&q=sending+files+winsock&meta=

easiest, quickest solution to most problems

Did you actually try that search? It's not very precise -- the entire first page is taken up with Visual Basic control discussions, rather than real WinSock examples.

However, sending a file with WinSock is very easy (assuming you're using TCP): you enter a loop where you read some data from the file, and send it on the socket; repeat until done. You should probably send the file name, metadata (attributes and whatnot), modification time and size before you start sending the file, so that the other end knows what to do with the file data.

So just send the file name, and then do files reads and send small chunks at a time and keep adding to the file until its all there?

yes, when I get home tonight I can post a snipped should be about an hour or so.
aswell what language are you using =P

I also advocate using TCP for auto-patching (in fact, if you have a central login server, I'd use it there too - makes for much simpler code), and switch to a UDP protocol for actual game servers.

First compare MD5 hashes on any assets that might need patching against your current versions' hash. If the hashes don't match, the asset needs patching. You don't explicitly need to use MD5, but you need an effective way of quickly comparing the entire contents of the asset. This can also be used as a measure of protection against pure asset hacks.

You might not want to compare all assets, so you should work on a patching strategy - for example, introduce a patch first as optional (someone has to explicitly check for updates to get it), and mark it with a date that it becomes mandatory. Running a hash on a collection of hashes (block) also works, so you can determine if a particular branch of the asset tree needs examining in more detail.

You can now use a delta patch method, or replace the whole asset. There are a number of delta libraries around that are free, and produces very small binary deltas anc code to apply the patch - try http://cvs.gnome.org/viewcvs/xdelta/doc/xdelta.html or have a stomp around google.

Hope this helps.

It doesn't make a whole lot of sense to use UDP for copying down patch files. For that sort of thing you want a streaming, reliable, connection-oriented protocol and there's no sense reinventing the wheel when TCP does all that for you anyway.

for a chat server, like irc, would tcp be enough, even though you are handling 100s or 1000s of connections? You are just sending text, so I don't think it would be that bandwidth or computer intensive...

Please erase MD5 knowledge from your memory, it is completely dead and useless at this point. Do not trust anything that uses MD5 to authenticate anything.

http://it.slashdot.org/article.pl?sid=05/11/15/2037232&tid=172&tid=93&tid=228

From what I can see, this is just the ability to produce an MD5 collision.

Not necessarily too problematic - it is improbable that someone could produce an effective hacked asset with a colliding MD5. A garbage block with an MD5 collision, sure, but such blocks would not conform to whatever asset format is actually being used, and would therefore most likely be rejected by the code loading them. Whether this causes a crash or drop to a fallback asset is down to the implementation.

That said, I definitely would NOT use MD5 as a single tier of authentication now (such as for password checking).