1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Pure Sockets vs WebBrowser vs Other?

Discussion in 'Visual Basic .NET' started by captchaman, Sep 29, 2010.

  1. captchaman

    captchaman Junior Member

    Joined:
    Sep 16, 2010
    Messages:
    190
    Likes Received:
    842
    Occupation:
    Software Programmer
    Location:
    USA
    I'm well versed in VB6 and want to get back into coding, I have Visual Studio 2010 and Visual Basic .NET looks great. Most of my apps are HTTP based and I always used winsock just because it was so much faster and cleaner than the WB control but now I'm converting some old apps and I'm wondering, is it really worth parsing everything and writing custom functions all the time when the WB control is so easy and convenient?
     
  2. smack

    smack Junior Member

    Joined:
    Feb 1, 2010
    Messages:
    182
    Likes Received:
    78
    Occupation:
    Software Engineer/Evil Genius
    Location:
    inside .NET
    the web browser control is bloated, buggy, inefficient, doesn't do multi-threading, and does a piss poor job using proxies.

    the System.Net.Sockets namespace is where it's really at, but if you don't feel like going there you can get by with HTTPWebRequest. HTTPWebRequest isn't nearly as solid, fast, stable, or flexible as the sockets namespace, but it is light years better than the web browser control.

    -edit-

    i have some fairly detailed posts on the difference between the three of these and some very good links to help get you started. just search for other posts by me.
     
  3. Crazy

    Crazy Jr. Executive VIP

    Joined:
    Jun 13, 2009
    Messages:
    640
    Likes Received:
    319
    Occupation:
    VB, C#, XHTML, CSS, PHP, MySQL, JavaScript, jQuery
    Location:
    Everywhere
    Honestly, it all depends what you're trying to achieve. When I first got into coding in VB, and my first spammer (CGI spammer) I used the WB control (and subsequently called my spammer webbrowser lol). But, as I got more advanced, I slowly moved exclusively into winsock. It just gives you the full control you need when working with this kind of marketing. Configuring your own headers and working things step by step, imho, is the best way to do it. Granted, you have to manage cookies, parsing form values, etc. But at the end of the day it's faster, provides more control, and like you said... cleaner.

    I'm also moving from VB6 to .Net. I'm very experienced in VB6. The research I've done has yielded a few things. (1) The winsock control can be used within the .Net environment, however it's both discouraged and, more importantly, unstable. (2) The HTTPWebRequest class is a glorified inet.ocx (such as that used in VB6). It's more advanced, but essentially the same thing. By that I mean, you can't use SOCKS protocol proxies, you can't really configure headers as freely as you'd wish, and it's just not as flexible as winsock. The Sockets class, however, is the way to go. I've done some research and it indeed is just pure raw data over a TCP connection, as was like using winsock or the Win32 sockets API. I haven't learned how to use threading or the "lock" feature of VB.NET so, that's kinda what's been holding me back. But I'd suggest you just take the time and learn to work with the Sockets namespace. I think it'll be the best bet in the end and fit almost everything you'd need to do.

    If you ever wanna work together on learning or sharing notes just hit me up.
     
    • Thanks Thanks x 1
  4. smack

    smack Junior Member

    Joined:
    Feb 1, 2010
    Messages:
    182
    Likes Received:
    78
    Occupation:
    Software Engineer/Evil Genius
    Location:
    inside .NET
    hey crazy, didn't see this reply before i responded to your PM. clears up a few of my questions. ;)

    threading and locks in .NET are very easy to implement, they can be a bit harder to get right in some instances though. one of the nifty new features of framework 4 is that many of the collection classes now implement a thread safe means of adding and removing items from the collection without having to explicitly take out a lock.

    for simple increment, decrement, and value swaps of primitives types there is the Threading.Interlocked class. it is far more efficient than using using the SyncLock statement (lock in c#).

    the SyncLock() statement is another technique you can use to lock code blocks during multi thread operations. use it with care though, and only lock what and when you need to. being judicious in its use can help mitigate the risk of race and deadlock conditions.

    you also can use Mutex as well to synchronize threaded operations. although this i haven't had very much experience with at this point, so i can't directly speak to it.

    back to the topic of http protocol, i highly advocate making friends with the sockets namespace. taking a little time to build yourself a nice http class based on that will pay dividends well in to the future. i've had more than my share of strange issues and behaviors in programs relying on HTTPWebRequest, and in some cases even requiring some down right silly hacks to get it to operate correctly. again, it is far and away better than the web browser control for a plethora of reasons but in reality it will only get you so far.

    there is of course always the option of going with a 3rd party http class like chillkat or something similar. but i am a "roll your own" type of guy, and with the exception of the classes and functions that my friend makes, i steer well clear of them whenever i can.

    side note, my friend made an absolutely insane http class based on the sockets namespace that i have had the good fortune to be able to build many programs around. he has done several versions of it through the years and with each successive release improves upon it. it really speaks to what you can accomplish when you have a good handle on the sockets namespace and it is the primary reason i so heavily advocate for learning to use it. i have used its power, and it is pretty damn kickass. especially when compared to the other available options. ;)
     
    • Thanks Thanks x 1
  5. captchaman

    captchaman Junior Member

    Joined:
    Sep 16, 2010
    Messages:
    190
    Likes Received:
    842
    Occupation:
    Software Programmer
    Location:
    USA
    Thanks for the replies, you guys are awesome! Looks like the sockets namespace will be priority #1 and WebBrowser whenever something is a bit too complex since I'm just learning at the moment. I also got some valuable information about Multi-threading which is great because that was screwing me around earlier today in a test project since I really don't know anything about it coming from VB6.

    Another question that I had which will undoubtedly be very important is reverse engineering protection. I see that LogicNP has what looks to be quality software but depending on a third party for security is never short of failure. In VB6 I would throw in a bunch of random fake security functions at different times and have the true checks obfuscated and few and far between, then when the true check failed it would make a vital program function stop working as silently as possible. On top of all that I used different debug checks and VB6Obfuscater, then compiled in P-Code and used a third party software. I'm just worried about all the code going through the engine and being easily accessible because I'm a knowledge-less n00b, or will I be able to do the same and have the same effectiveness?

    Cheers
     
  6. crepito

    crepito Junior Member

    Joined:
    Oct 5, 2008
    Messages:
    145
    Likes Received:
    28
    Location:
    Portugal
    Sockets > httpwebrequests > ... > webbrowser component.

    Currently i'm only using httpwebrequests to perform my needs but i'm thinking of diving deeper and start using sockets.
     
  7. smack

    smack Junior Member

    Joined:
    Feb 1, 2010
    Messages:
    182
    Likes Received:
    78
    Occupation:
    Software Engineer/Evil Genius
    Location:
    inside .NET
    a determined person will always be able to get the code if they have enough knowledge and persistence. however, a good starting point is the Dot Obsfuscator that ships with the .NET IDE. they give you the community edition for free, and you can purchase more advanced version if you so desire.

    in many ways .NET makes it a bit tough on developers to keep their code private. the assemblies are more or less made to come apart thanks to the reflection abilities inherent to the framework. these features are wonderful when you need to prepare something for COM interop, but not so great when you want to keep proprietary code safe.

    RedGate's reflector is a great tool for looking in to then guts of .NET executables. i use it regularly in development for a variety of reasons including peering in to the inner workings of some of the framework components. it's free, and definitely worth a download. it's nice to be able to see what is being provided to you by others, and also to reflect on your own code. especially if you're trying to obfuscate your code for protection. it will give you a window in to just how jumbled (or not) that your code will look.