1 (edited by kianoosh 2018-04-05 10:23:34)

Hi there. I recently begun to learn C# seriously and well, I was kindda success! The only thing that i can't understand correctly is networking in C#. You know it's not complicated but it's kind of hard to debug for me. I tryed to code a client and server program. Server started correctly but when i tryed to connect to it using the client server crashed. I don't know why and i was using C#'s system.net standard. So i left that thing and heard about E net. I got the library from newget packages and started to mess with it a bit. The problem with that library was that it doesn't have a good tutorial. It has just an API reffrence which how ever, i could get some stuff out of it and could setup my app but i never could understand how to send or recieve packets with that library. Could someone give me a tutorial for E net, or interduse a better library if known please? Thanks for reading

Add me on skype: kianoosh.shakeri2
Or follow me on twitter @kianoosh shakeri

Thumbs up

2

The System.NET namespace is pretty powerful, but also low level. There are many reasons why your program might crash. You could get a time-out exception, a read/write error, etc. The good thing about managed languages is that they will give you stack trace information: you will get the error, as well as where it occurred. So, take a look at that and see if you can get any hints from it.

If nothing else, post your stack trace here and I'll try to help you debug it.

Thumbs up +1

3 (edited by kianoosh 2018-04-08 20:05:45)

Hi there. I recoded the thing, it executes the functions just it seems it doesn't comunicate correctly. Here's my code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using System.Net;
using System.Net.Sockets;
namespace Client_server
{
    class Program
    {
        private static void server()
        {
            TcpListener serversocket = new TcpListener(11232);
            TcpClient client = default(TcpClient);
            serversocket.Start();
            Console.WriteLine("server is up! ");
            client = serversocket.AcceptTcpClient();
            while(true)
            {
                NetworkStream net = client.GetStream();
                byte[] bfrom = new byte[20000];
                net.Read(bfrom, 0, bfrom.Length);
                string event_message = Encoding.ASCII.GetString(bfrom);
                if(event_message=="pat")
                {
                    send(net, "stuff");
                    net.Flush();
                }
            }
            void send(NetworkStream net, string data)
            {
                byte[] outst = Encoding.ASCII.GetBytes(data);
                net.Write(outst, 0, outst.Length);
                            }
        }
private        static void client()
        {
            TcpClient client = new TcpClient();
            client.Connect("127.0.0.1", 11232);
            while(true)
            {
                NetworkStream net = client.GetStream();
                byte[] bfrom = new byte[20000];
                string event_message = Encoding.ASCII.GetString(bfrom);
                bool b = false;
                if (b == false)
                {
                    string dat = "pat";
                    byte[] outst = Encoding.ASCII.GetBytes(dat);
                    net.Write(outst, 0, outst.Length);
                    net.Flush();
                    b = true;
                }
                if (event_message=="stuff")
                    {
                    Console.WriteLine("you are stuff");

                }
            }
        }
        static void Main(string[] args)
        {
            Console.WriteLine("started the app");
            var ser = new Thread(server);
            ser.Start();
            Thread.Sleep(250);
           
            var cli = new Thread(client);
            cli.Start();
            Thread.Sleep(250);
            ser.Join();
            cli.Join();

        }
    }
}

Add me on skype: kianoosh.shakeri2
Or follow me on twitter @kianoosh shakeri

Thumbs up

4

@kianoosh, multiple things:
1. I noticed your byte arrays. They are ridiculously large for a networking application. You should never accept packets in 20000-byte chunks. That leaves so many vulnerabilities open to your system its absolutely unimaginable. The most efficient byte array size for your server is exactly the amount of data you know will be sent between the client and server; however, since this can never be anticipated, 1024 is the recommended byte array size for 99 percent of all networking applications.
2. You have no error handling here, and don't use half the namespaces you import. If your going to write a networking application, you first need to use error handling *everywhere*. Because an error may occur, any time, anywhere, and you certainly won't be expecting it.
3. You use threads and no mutexes. In this kind of application, a thread is entirely pointless. You won't acomplish anything with that, and it may explain your communications problem. What your doing here is joining both threads together and executing them at the same time, but they're pretty much being given access to the same data at the same time, causing a deadlock. And this is the first trip that most programmers, myself included, make when using threads: accessing the same data at the same time among two or more threads. This causes a deadlock; that is, both threads just sit there, waiting for one to release the resource they're trying to access, and neither ever does. On the other hand, non-use of mutexes can cause data races and many other problems you'd best deal with before they can ever arise.
Now, my recommendations:
1. Get rid of all those unused imports. You don't use them; it doesn't make sense to import them.
2. Decrease your byte array size to 1024 bytes, maximum. Never set your byte array size below 512 bytes. In some cases it is fine to have a buffer size of 2048 or even 4096 bytes each, but keep in mind that this array is constantly being allocated and released, and the higher the array size, the more memory usage your server will use.
3. Fix the error handling with generic try/catch blocks around everything, including your main() function, send(), server() and client(). And I don't mean wrap small little statements in try/catch, either. I mean wrap the entire function in them.
4. Either get rid of threads entirely, as, like I said, they're pointless here, since you can split them into separate apps entirely, or use mutexes and careful locking. Below is a sample of how to use a mutex:
private Mutex mutex = new Mutex();
//... in the receive method, wait for safe access...
            while(true)
            {
mutex.WaitOne();
                NetworkStream net = client.GetStream();
                byte[] bfrom = new byte[1024];
                net.Read(bfrom, 0, bfrom.Length);
                string event_message = Encoding.ASCII.GetString(bfrom);
                if(event_message=="pat")
                {
                    send(net, "stuff");
                    net.Flush();
                }
mutex.ReleaseMutex();
}
}
// Local function? End the server func.
            void send(NetworkStream net, string data)
            {
// We've already acquired a mutex by this point, so don't try reacquiring it (causes an indefinite block).
                byte[] outst = Encoding.ASCII.GetBytes(data);
                net.Write(outst, 0, outst.Length);
                            }
// ... same with the server client.
private        static void client()
        {
            TcpClient client = new TcpClient();
            client.Connect("127.0.0.1", 11232);
            while(true)
            {
  mutex.WaitOne();
                NetworkStream net = client.GetStream();
                byte[] bfrom = new byte[1024];
                string event_message = Encoding.ASCII.GetString(bfrom);
                bool b = false;
                if (!b) // No need to use b==false here, redundant
                {
                    string dat = "pat";
                    byte[] outst = Encoding.ASCII.GetBytes(dat);
                    net.Write(outst, 0, outst.Length);
                    net.Flush();
b=true;
                    break; // If we don't break, the condition won't be invalidated
                }
                if (event_message=="stuff")
                    {
                    Console.WriteLine("you are stuff");
                }
mutex.ReleaseMutex();
            }
        }
// Now we can use the threads together.
You can read more on Mutexes at https://msdn.microsoft.com/en-us/librar … 10%29.aspx

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up +1

5

Hello there,
First before i continue the reply just to let you know i am not trying to be mean in any way.

But my first suggestion:
Never use library's for networking.
Most networking applications need custom specific actions and handling.
So using a pre build library will limit you in the eventual project that you want it to be.
So that means you would have to go back eventually and write your own networking library anyways.
So that would be a bit double work.

The best way to  handle this is to really learn what the low level system in .net can do for you.
Starting from simply learning how the client and server functions interact with eachother
Including non blocking methods, Async calls and so on.

To find out more in depth studies on this i would suggest google for the terms: Async client server c#
This should get you in the right direction.
If you want personal help, i can offer the spare time to help you out on specific points and helping on programming the functions you need.

However like i said above and not trying to be mean.
You will never learn from copy and paste but only by typing and understanding what the code does.

So i know this is probably not very helpful in posting codes for you.
But as a teacher in programming i tend to give more word information then code.
It just takes time and  devotion to get what you need.

Kind Regards,
XSense

Homepage: http://xsense.venict.nl
Skype: xsense29

Thumbs up +1

6

@Xsense, you, uh, kinda *have* to use libraries. In everything. In every programming language. No, networking libraries to not limit you in any way. Your logic is extremely flawed.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

7

Sorry, but i am having trouble understanding your reply.

The only part i could understand and no offense ment.
Is that you are saying that it's better to use a pre build library then creating your own?

I would have to disagree on that.
As each project has their own properties their own capabilities


And building your own network client and server system has a lot more purpose.
1: It teaches you how it actually works.
2: You can learn what important steps for exploiting can be taken for example buffer overflows and so on.
3: Copy and paste work is simply not effective what does it teach you?

The network library in the .NET Framework has a lot of functions.
Ones that you should understand how they work, if you don't then a lot of things would make you go back into the code to correct issues later.
Of course this will happen anyways, but in y oppinnion.
It is always better to have an understanding of it as well.

Not only that but once you understand how packet traffic works you can then expand your knowledge for example.
For encrypting traffic using custom or pre made algorythms.
Which would make your network server and client secure.

Anywaysy,
Again i mean no offense but i am just trying to support another developer.
By giving them pointers and a bit of a pat on the back saying you can do it.

Regards,
XSense

Homepage: http://xsense.venict.nl
Skype: xsense29

Thumbs up +1

8

@Xsense, your idea sounds more along the lines of network theorems. "Its best to use a low-level library" is utter posh. You use what you have available, or use what you can make available. The worst thing you could ever do is communicate with the driver directly via its direct interfaces. That has to be the worst idea I've ever seen. Unless you absolutely know what your doing, never, ever directly send commands to the driver, and never, ever use a low-level interface that is a thin wrapper around the direct instructions to the network card. That's what high level libraries are for. Like .NET, for example. They abstract away the incredibly large lines of code you'd normally need to write to get something going. Its simply a very, very bad idea. Copy-pasting code is bad, I agree; but sometimes, it can be helpful. Most of the time its useless though. Also, you most likely *won't* learn much from using low-level network libraries at all; you'll most likely only be putting yourself through hell. If you were to walk up to a professional programmer or computer scientist and tell them this idea, they'd laugh in your face. Like I said, don't ever consider dropping to the really low APIs unless you're project has requirements so specific that you require such a level of control. Otherwise, don't even think about it.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

9

I don't know if i have offended you in anyway if so then sorry.
But if you read my post carefully.
I state clearly that he should look into the details of the .NET Framework net library and study it so he can understand the functionality of it.

There's a reason why c sharp is a managed language and not unmanaged , so you dont need to deal with all the low level management.
So perhaps what you mis understood was that i mean he should not use library made by 3rd partys like you can find on codeproject or such.
But to study the framework included in the .net framework.

Anyways about programmers laughing in my face,
I would say if that is what your perspective is of what i am saying then fine so be it.
Everyone may have their own opinnion and as such so are you.

Thats why i usually read twice and try to listen to what someone says before responding in a such a way.
So let me try to make myself clear, since even  though my english should be readable , even  though its not my native language.


To the poster of this topic.
What i am trying to say in a helping way is.

Try to study a bit on networking with the .net framework.
A lot of it can be found on microsoft website it self.
I would post my own client and server library's but i dont see how that would help you in the long term.
The reason why i am saying is using other library's that 3rd party developers made.
is that you might need a lot of different content for your project.
Which would mean that eventually you would have to customize it to your needs.
And when you reach that point you would have to know what function does what and how you can add more functionality to it.
So to the poster again, i am not trying to be mean but just helpful.
If i am not then please ignore my post.

Since the best way to make something is to understand it.
And if you have specific questions on implenting client / server communication in c sharp i will gladly help you in the spare time i have.

Anyways i am going to leave this topic now.
As i am getting pretty much annoyed by it.
I will be available per email if you need help on creating a client and server.
By the way just my personal opinnion.
But whenever i create a game server / login server etc.
I have done many for mmorpg's / emulation.
What i do is i seperate the main server from other major server needs.

For example:
Login server would communicate for client login.
The login server once a successful login is done would communicate the information towards the update server.
Once that would be done it would communicate to the gameserver using a ipc server.
That would grab the client and take over from the login server.
Then the login server is not a main server so packet handling could be done seperatly for multiple purposes.
Anyways just my 2 cents.
Like i said i am leaving this topic now.
So if you want to have my own client / server programming i can send it.
Or if you want to learn more aboutit that you cant find online.
Then i will try my best to help you out.

If not , i wish you all the best on your project.

Regards
XSense

Homepage: http://xsense.venict.nl
Skype: xsense29

Thumbs up

10

Don't worry about Ethin Xsense, he talks like this to almost everyone. As with most communities their are bad apples and he is one of them. He's done this kind of thing for years and the moderators haven't gotten rid of him yet for some reason, and if you assume that I'm just saying this because I have something personal against him than, well, your partially correct LOL, but I promise that if you ask pretty much any long time user of the forum than they will say the same thing. I'm sorry you had to take that kind of abuse in a community that is supposed to be welcoming, but I promise you that that is not the norm among the coders here, and your helpfulness is seriously appreciated!


Your doing it again Ethin... The incredibly condescending attitude and arrogant choice of words. I thought you said you would try at least? This guy just put out a proof of concept demo for an actual game, plus he's planning on giving out the 3D engine for free. What have you done for the community lately?
Even if he was wrong, and it seems to me that it's just a difference in method rather than any inherently flawed concept that he's showcasing, you could at least try and refute it with the professionalism of the coders you emulate.

This... -- Is CNN'.
Well Ted, it sure looks like there's been uh, quite a bit of violence around here
"aaoh, that violence was terrible'!"
Yeah it was, pretty bad.

Thumbs up

11

Ok thank you for clarifying this for me, appriciate it.

Homepage: http://xsense.venict.nl
Skype: xsense29

Thumbs up

12 (edited by defender 2018-04-11 02:06:00)

Your welcome, and I am going to do some research to help you find voice actors for free, they are out their, and you won't find much on here in a reasonable amount of time. Luna stories sounds very exciting and without going into a ton of detail, that open source engine will probably help us greatly in having far less stale games around here. Also it's very selfless of you that you would offer to help these coders one on one with your limited time.
Again most bad apples in the community don't post much, those that do are usually just annoying rather than harmful, this guy is one of the few exceptions.
I already reported post 8 and if you feel insulted, which I would if I were you, than you can do the same.

This... -- Is CNN'.
Well Ted, it sure looks like there's been uh, quite a bit of violence around here
"aaoh, that violence was terrible'!"
Yeah it was, pretty bad.

Thumbs up

13 (edited by Ethin 2018-04-11 02:09:42)

@defender, considering the fact that I haven't violated any rules in my so called "arrogants" as you put it, the mods "execution" of me, if you will, would be unjust, as there isn't a rule against arrogants. If there was, I'm sure not only me, but you, and many, many other people would be out of here. I have rebutted his claims about lower-level libraries being a better way by stating that higher-level libraries are much better and safer because you don't have to learn knowledge you'll probably never use. In post 4 I stated problems in the OP's code. None of that was arrogant in any matter; it was an opinion. There is a hue difference between arrogants and an opinion.
Edit/update: While post 8 may have been a bit insulting, most developers will state things that they find wrong like this. Its very, very common. They may not be so brutal, but the message will be the same.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

14

@post 3:
Don't use a byte array this large. Figure out what your packets might be, or gbetter yet attach a length header to your packets being the first two bytes, then read two bytes, see if the length is valid, then try to read that next amount.
I would also recommend splitting up server and client.
@post 4:
There's nothing anywhere that gives these numbers that you say. a 20k byte array is not a security problem, and if so please show proof. I do agree that they can be smaller, see above.
The rest of your information for the most part is your usual misinformed drivvle, please queue your crying and complaints now as I yet again show you why it's wrong.
#2: I agree that there needs to be error handling, look at the exceptions each of these methods throw, but unused imports aren't a problem. It could be cleaned up, but if you've spent any time in .net, you know a lot of these are default and there's no real need to remove them out of hand.
#3: A mutex is not going to solve the problem here. He creates a server and a client, and the client connects to the server. They do not share data, thus no mutex is required. Should they be separate? Certainly, but not for the reasons you recommend. A mutex would not be useful here. There is no deadlock.
recommendations from post 4:
#1: see above about default imports
#2: see above about my packet header information. 1024 isn't a bad number, but it doesn't have to be a max. 2048, 4096, they're all fine (if possibly overkill) Worst case you just read into a stream or something and keep filling it up until you can't read anymore, or just fill a stream and try to parse. There are various ways to handle this. There's no hard rule about a min and a max for a byte array.
#3: Writing an entire function in try catch statements is the exact wrong use of try-catch statements. A try-catch block is strictly to handle exceptions thrown by a method, then maybe clean up with a finally block, not to wrap in an entire function. There could be multiple calls to multiple methods which all throw the same exception, and you would want to potentially handle those differently. Wrapping everything in them is abuse of a tool and will just lead to you silently dropping errors on the floor.
post #5:
There's a time and a place for libraries, some libraries like raknet solve some pretty helpful issues, and networking in general is a really tough thing to get right. I disagree that you should never use libraries, and system.net is hardly a library, it's a wrapper around winsock.
I think what you're saying and what I will second, is that you should understand low-level networking before you jump to using a library to make networking more simple, so I recommend OP continue on this path.
#8:
He's not saying to connect to the driver, he's saying to learn and understand system.net and how sockets in general work before moving on to something else.

Thumbs up +2

15

@sorressean:
And, as usual, whenever I say something wrong you lash out at me like its a personal insult to your very being. Considering that you agreed on some of my points, it wasn't all dribble, was it? Yes, in .NET, more than one method can throw the same exception, and handling of them can be done via single try-catch blocks, but for methods that connect and send data, like he's doing, handling all exceptions like this is OK. The mutex was a recommendation, not something I said that he had to use. The OP did not need to implement it if they did not want to. It was more of a precaution in case he did decide to share data; better to have it there in case you might, than to have it not and then to have to implement it. Again, that was a recommendation, not a demand.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

16

I'm simply showing you why, yet again your all-knowing arrogant oppinions and your haste to spew copypasted code and invalid oppinions you are wrong, yet again. It's not a personal insult, with exception to the fact that you call yourself a programmer which is laughable at best. I recommend you go play with legos, because when facts hit the fan, you retreat into playing the victem and wondering why people stop to take the time to explain why you're wrong.
Let me break this down for you. I agreed that error handling is a good idea, but standing on the fact that I agreed with one of multiple points is like buying a broken clock and claiming that it's at least right once a day. The clock is pretty useless for the rest of the day, but I suppose we all take what we can get.

Handling all exceptions in methods that connect and send data is not correct, and here's why.
First of all, if you just blindly wrap your code in try-catch blocks, you will not get the exception stack which helps with debugging.
Second, multiple of these methods throw the exact same exception. So given that, your code flow consists of something like this:
try
{
connect;
send;
}
catch(...)
{
...
}
Now you want to be able to handle certain things properly depending on what happened. If you're sending multiple chunks of data, you want to know where the exception was thrown, and not being able to tell if it came from the connect call or the send call is problematic. If you can't see this, I don't really know what to tell you except go get some experience and we'll talk after. This is not acceptable, and as you said earlier, if you talk to any real programmer, they'll laugh. The point of exceptions is that you can handle exceptions at the point where they're thrown, and be able to reason and know exactly where they were thrown without just wrapping huge chunks of code in a block. Your suggestion that you also wrap a try-catch block around main is also quite absurd and shows that y ou have little to kno experience with the tools of which you speak. Again, you would have to know what to catch, and if exceptions are being thrown that far up the stack there's something wrong and it should be allowed to abort, not just be silently caught and thrown on the floor. This kind of programming makes debugging hard, testing hard, and hides errors that will present themselves during runtime which you could fix.

You state that the OP should use mutexes because there's a deadlock; this is stated as fact, not as a "you might want to do this":
"What your doing here is joining both threads together and executing them at the same time, but they're pretty much being given
access to the same data at the same time, causing a deadlock. And this is the first trip that most programmers, myself included, make when using threads:
accessing the same data at the same time among two or more threads."
There are various things wrong with this; first, that it's not posed as something to look into in the future, second that a mutex (especially in your code) is wrongly used, third that a mutex isn't used, and finally, you have some issues with your understanding of threads.
Calling .join on a thread is not "joining" a thread together. It simply waits for that thread to finish before exiting. Without this statement, the main thread will exit, thus terminating the other threads. You are not joining the two threads together, just blocking until they exit.
If you create two threads, thread a and thread b, and then do:
b.join()
a.join()
it will wait for b to finish; if b finishes, it will wait for a to finish. If a is already finished, it will return and thus the main thread can terminate.

Thumbs up

17

I also find it interesting that you suggest the wrongful use of a lock in the form of a mutex just in case you want it (which really isn't any way to program at all), but you spent so much time complaining about the fact that he was importing assemblies he wouldn't actually use. One is totally fine and won't cause any problems, the other is a misuse of a mutex and will most certainly cause problems. Just some food for thought. We can now return to our regular programming, defensive victem being attacked everyone hates me yada yada yada.

Thumbs up

18

Doing it again are we @4, 6, 8, etc.  *sighs* I don't have the energy right now to deal with you.

I'm a cat! What's mine is mine, and what's yours is mine to :P XD

Thumbs up

19

Yeah, I was talking about post 8, and I guess partly post 6 as well.
And your right, we would all be up a creak with no paddle if arrogance was punishable around here, but I can't remember a time when I responded to benevolent misinformation with such unreasonable harshness.
Maybe back on that UP topic a long time ago, but I actively tried to change, and it doesn't really seem like you did...
Again even if the guy is being unrealistic about the skill of a newcomer to this language, their is no reason to treat him like shit, especially since he's your superior in terms of real, tangible application of knowledge.

This... -- Is CNN'.
Well Ted, it sure looks like there's been uh, quite a bit of violence around here
"aaoh, that violence was terrible'!"
Yeah it was, pretty bad.

Thumbs up

20

Just to add my opinion to this topic.
Ethin:
You need to think before you post, for the love of god. While I am not nearly as good a programmer as others on this thread, from the way all of you write, and the things I have seen from you in the past, I would trust everyones opinion, except yours. Your attitude to the op is immediately condescending. When a different opinion from yours is stated, you get defensive, and the condescension level grows over 9000.
I think it would be a good thing for you to learn that lashing out is not the only way to react to differing points of view. Discussion and agreeing to disagree are useful tools which you appear to lack. They may even help you learn something, and will definitely cause you to be the recipient of posts such as the one I am now writing far less often.
If that bothered you, you may now understand some of what others feel when they read many of your posts.

Praise be to cthulhu, the one who will emerge from the depths and devour all that lives.

Thumbs up +2

21

The reason you want a buffer as small as possible is because a malicious program could fill the left over space in your buffer with god knows what. It might be code they want executed as in an SQL injection or data they are trying to exfiltrate from your machine. These are just two things I could think of off the top of my head after a long day of classes, hockey practice, and homework.

personally don't really see the "arrogance" people say Ethin is displaying. I am more of a lurker hear so i read a lot and don't really think its warranted. He posts a lot, usually fairly high quality stuff, that isn't baseless. "arrogance" is hard to attribute here partially because much of speech is word inflection, tone of voice, and emphasis. all of which is lost in a text-only medium. Granted, part of speech is word choice, which is not lost, but i think this is less of a factor personally.
If its so upsetting to you that Ethin is posting away with all of his arrogance, how about just not reading his posts? responding in they way I see people doing is just making the problem worse by filling up threads with useless junk posts.
The reporting tool needs to be used for posts that clearly violate the forum rules or is spam. not for our petty grudges. We aren't children anymore. lets try and at least put up an appearance of  acting like adults. instead of all of this petty bs back and forth.

I don’t believe in fighting unnecessarily.  But if something is worth fighting for, then its always a fight worth winning.
check me out on Twitter and on GitHub

Thumbs up

22

Okay, so I've stolen data from your system, crafted an sql injection attack, whatever and for whatever reason I've decided to put this in your buffer. What exactly happens now? How is this a security risk. It might slow things down as you try to read that size, it might allow me to slow your connection by sending 20k bytes, but really, where's the security issue here. Meaning, how would you as an attacker move from stashing data you stole, in your scenario in a 20 k byte buffer to making that data do something? If that data is stolen, sending it back to you isn't going to matter, it's stolen. If I write a sql injection attack and it somehow runs on your system, the buffer size isn't going to matter because most injections don't take 20 k bytes to write. There's literally no explanation what so ever for limiting the buffer size due to security reasons.

Thumbs up

23 (edited by Ethin 2018-04-11 05:42:52)

Thank you, Kyleman123, for stating that so eloquently. Plus, I find it kinda hypocritical when someone says I'm arrogant, then goes to correct me and acts just as arrogant, if not outright insulting, right back. That doesn't exactly help the situation at all, and only puts fuel on the fire. Also, what I think Kyleman123 means to say is the way the transmitted bytes can be handled by an application. The larger the buffer size, the more data you can scan, and the higher risk of junk/nonsense being inserted into the data stream (as well as the higher amount). Such nonsense could include SQL injection attacks, machine code, etc. If you limit the buffer to 1024/2048 bytes, you can discard the rest of that nonsense (since, really, it can still be inserted into the stream, the buffer size being irrelevant since most, if not all, insertions are done through the client and then through transmission from the client, or through an intermediary such as an MITM). But limiting the data means you only read 1024/2048 bytes at most. If that contains unrecognizable code? No issue; discard it and move on. Allocate a buffer of 20000-40000 elements and that's 20000-40000 more bytes to process. That takes time and memory, and considering that that buffer is always allocated and released.... well, its probably possible to crash a system that way. I really don't know, I'm not dumb enough to try. smile

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

24

There are potential attacks I can think of, but these all have to do with denial of service rather than using the buffer size to somehow exploit the server, so I'm really struggling here to understand where the security concern is.

Thumbs up

25

Okay okay, I put fuel on the fire. Now that you've accused me of doing what others are accusing you of doing, would you care to back up Kyleman123's post, or any of your own claims, or literally just add anything constructive to this post apart from whining that you're being treated unfairly? The former helps explain your point, the latter just takes up more posts. I've provided counterpoints to each of your statements that you have decided to refute, so, I'm waiting to see some information. If you respond to someone's post and 90% of what you say is wrong, why exactly is it an issue that people attack you over it? Could I be nicer about it, sure, but that road hasn't helped all that much in the past. Do you deserve to have people tell you time and time again as nice as possible while you're treating people who you believe are your inferiors like garbage that you're wrong? No, probably not. Does it make sense that people are getting frustrated with your constant track record of providing misinformation? I think it does, as the attitude you approach the subject with and the information and then your attempts to play the victem each and every time someone proves you wrong gets very tiresome after a while. I'm quite honestly failing to understand why you're upset over this, these people ask for help, and they at least deserve a minimum of your silence, and if not that, then you considering taking the time to provide proper knowledge. If you think that it's okay to fail 95% of the time, perhaps you need to consider your own skill set, your insecurities and evaluate just how much you know.

I say all of this, Ethin as someone who has been in your shoes. As someone who acted just like you years ago. I thought I knew a lot about programming in general and felt totally justified in being a total asshole to people who dared ask for help, and when I provided it I was way off the mark. You have potential, and I'd really rather see you actually learn and put that to use rather than spreading misinformation and then ending in flame wars when your feelings get hurt because you're called out on it.

Thumbs up +1