SocketNetwork[help]

ok im making my own server here and stuff but any way hybirds socketnetwork.dll
what do you all thank about it?
im thanking about using it on my server because its easy but does it work good?
please reply and tell me why.
btw im working with 5017 Client.


and can you all give me some advise on the packet handling system as well thanks.

:handsdown:

Hybrids sockets<3

Mhm, Impulses sockets <3

Coding your own and researching into different types using Google is always the best option.

thanks fang, can you all give me some key terms to look up or anything like that?

Quote:

Originally Posted by taylor2846 ok im making my own server here and stuff but any way hybirds socketnetwork.dll what do you all thank about it? im thanking about using it on my server because its easy but does it work good? please reply and tell me why. btw im working with 5017 Client. and can you all give me some advise on the packet handling system as well thanks. :handsdown:

My original hellmouth source was written using hybrid's nativeinterop dll. Shouldn't be an issue on 5017 but there are a few native calls that will fuck up because it's trying to load dlls twice or something (never looked into it, I just know it was hella annoying so I switched, then later I reflected his dll and made my own with the memcpy calls switched to Buffer.BlockCopy).

As said, writing your own socket system would be IDEAL but keep in mind you will want to do a large amount of debugging and stress testing on your sockets. You can write a BASIC socket system *cough* sync anyone? *cough* super easy but if you try to pile an entire functional server ontop of that base it will topple over and you'll be back where you started.


What people so often fail to consider is that when dealing with writing or using a source, it's value is determine by the importance of stability and efficiency in it's various components.

Obviously the ideal solution would be flawless efficiency and stability in all areas of the server but lets face it... that will NOT be the end result (look at even professional products. It's quite often that these things are sacrificed or forgotten in favor of production time or saving money at some point). The point here is keep these things in mind as you develop your source.



Handy graphics I decided to whip up.


[Only registered and activated users can see links. Click Here To Register...]

[Only registered and activated users can see links. Click Here To Register...]

Quote:

Originally Posted by taylor2846 thanks fang, can you all give me some key terms to look up or anything like that?

Socket, TCP, C# client&server connect

Look up types. All research starts from one point and moves towards an end product. If you let other people define and limit your findings, you won't get a good end product. People here don't want to help you: it's how the community is here- and I understand. Why should anyone who spent hours researching into new methods and implementing them into their source give it to you? It's at the same access level- you just have to find it for yourself. Also, don't trust the direction people give you. Set out in your own direction- because most of the time ... they're wrong.

PS: Don't trust people that set a direction for you not only because most of the time they're wrong- but because they know they're sending you in the wrong direction.

whats a good way to test your socket system?
other then getting tones of people to connect

Quote:

Originally Posted by taylor2846 whats a good way to test your socket system? other then getting tones of people to connect

Stress testing.

Accurate stress testing is hard to do...
You could make a program that sends a packet a second per socket and has a counter.
You'd have to run it on another computer and network though.

If I were you, I'd make it so the socket system can be removed and replaced very quickly (like Plug-and-Play). That way when you test it and you find a problem with it, you can work on it in a new project and then implant it in the source during a short server maintenance.

Quote:

Originally Posted by Fаng Accurate stress testing is hard to do... You could make a program that sends a packet a second per socket and has a counter. You'd have to run it on another computer and network though. If I were you, I'd make it so the socket system can be removed and replaced very quickly (like Plug-and-Play). That way when you test it and you find a problem with it, you can work on it in a new project and then implant it in the source during a short server maintenance.

Or do something like this: