Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jun 2003
Offline Last Active Yesterday, 07:28 PM

Posts I've Made

In Topic: best way to send an receive multivarible data by socket

14 December 2014 - 07:18 PM

you just can set some varibales into an string

Several suggestions above indicated why this is a bad idea. For example, string manipulation in C# generate lots of garbage, and the string encoded values will use more bandwidth (as they are longer than equivalent binary encoded values.)

In Topic: extreme NAT punchthrough, UDP over DNS :p

14 December 2014 - 12:41 PM

Points for creativity :-)

Here are some challenges you'd have to overcome:

1) DNS is heavily cached. The time-to-live for various DNS entities is measured in hours, not milliseconds.
2) Many ISPs actually intercept DNS and resolve it themselves, rather than forwarding to an external DNS server. For example, Comcast does this, to send you to their own ad-filled "search help" page if you mis-type a domain name.
3) Most pay-for hotspots that I know about hijack both DNS and HTTP/HTTPS to bring up a "please pay now" paywall for whatever the first request is that your browser makes.
4) Some ISPs with strong "intrusion detection" systems (to clamp down on botnets and whatnot) may detect your unusual traffic as malicious.

Good luck, and please let us know how it goes :-)

In Topic: 30k concurrent players on a (private) MMO server...is this possible ?

14 December 2014 - 11:54 AM

The size of the map almost doesn't matter (as long as you can reasonably fit it in RAM for clients and servers.)
If the amount of data needed per tile is average of 32 bytes, then a 1000x1000 map would only take 32 MB.

In Topic: TCP clients-servers-servers

13 December 2014 - 09:18 PM

They feel more like fantasy death-matches than an MMO

Because that's what MOST people pay for.

Some other games have been made successfully, though, like the A Tale In The Desert series.

In Topic: best way to send an receive multivarible data by socket

13 December 2014 - 04:00 PM

Check out the BinaryWriter and BinaryReader classes.

Note, though, that the TCP stream will not tell you where one packet ends and another starts. Thus, you need to prefix each packet with a length in itself.
Thus, you typically generate a packet by writing data using a BinaryWriter to a MemoryStream, then get the length, and write length (as a two byte ushort, typically) and the actual data from the MemoryStream. When receiving, you do the reverse: wait until there's at least two bytes read the length, then read that many bytes, stuff it into a MemoryStream, and use a BinaryReader to read the data back out.