How to Download Image Through vb6 Winsock/vb.net socket?

Attachment 147477

Please Look at the Picture. I need to download The Image data from Data Arrival. But I can't split the Header data to save the Image in my Computer. Is there any way to save the Only image data as jpg image in computer ? Please

Well, I was starting to explain how the HTTP protocol has a really easy-to-detect pattern to tell you where the end of the headers is, but then I realized in .NET we very rarely use the Socket class for this very reason. Socket is good for low-level access or implementing your own protocols with optimizations, but that low-level access also makes it more complex. For general networking tasks, TcpClient and UdpClient are less fussy but still require you to roll your own protocol layer.

That's why we have HTTP-oriented types like HttpWebRequest, HttpClient, and WebClient. Each of those is in order of increasing level. That is to say they're in this order:

• Socket <---- Complete control, very complex to use
• TcpClient/UdpClient
• HttpWebRequest
• HttpClient
• WebClient <---- Very easy to use, hard to specialize

Downloading a PNG image with WebClient is super easy:

Code:

---

Dim client As New WebClient()
client.DownloadFile("http://example.com/yourfile.png", "yourfile.png")

---

Since it assumes HTTP, it strips the headers for you.

It's a little more work to do so with HttpClient, but you can do more of the configuration yourself. It's a little weird because it's very heavily Task-based, I'm pretty sure you need at least VS 2013 to use this (and the syntax might need tweaking):

Code:

---

Dim client As New HttpClient()
Using response = Await client.GetAsync("http://example.com/yourfile.png")
    Using (output As New FileStream("yourfile.png", FileMode.Create))
        Await response.CopyToAsync(output)
    End Using
End Using

---

Again, since it assumes HTTP it strips the headers for you. It's more obvious how to set up cookies and other details for this type than it was for WebClient.

With HttpWebRequest, you get a lot more control over all the details, and unfortunately that means you HAVE to set them up yourself. Its abstractions for working with files aren't quite as nice, but are still nicer than having to parse HTTP yourself:

Code:

---

Using request = CType(WebRequest.Create("http://example.com/yourfile.png"), HttpWebRequest)
    request.Method = "GET"
    Dim response = CType(request.GetResponse(), HttpWebResponse)
    Using output As New FileStream("yourfile.png", FileMode.Create)
        Using responseStream = response.GetResponseStream()
            responseStream.CopyTo(output)
        End Using
    End Using
End Using

---

Next up the list is TcpClient/UdpClient. At that point, you have to create/parse HTTP headers yourself, and I don't believe it's worth it. It'd take 10-15 lines of example code just to send the request.

Note that if for some reason you HAVE to save this .png file as .jpg, you need to do a little more work. That involves downloading the data for the .png, loading it into memory as a Bitmap, then re-saving it using JPEG encoding. I don't think that's worth it, either, but you may have some technical reason.

Quote:

---

Originally Posted by Sitten Spynne

Well, I was starting to explain how the HTTP protocol has a really easy-to-detect pattern to tell you where the end of the headers is, but then I realized in .NET we very rarely use the Socket class for this very reason. The socket is good for low-level access or implementing your own protocols with optimizations, but that low-level access also makes it more complex. For general networking tasks, TcpClient and UdpClient are less fussy but still require you to roll your own protocol layer.

That's why we have HTTP-oriented types like HttpWebRequest, HttpClient, and WebClient. Each of those is in order of increasing level. That is to say they're in this order:

• Socket <---- Complete control, very complex to use
• TcpClient/UdpClient
• HttpWebRequest
• HttpClient
• WebClient <---- Very easy to use, hard to specialize

Downloading a PNG image with WebClient is super easy:

Code:

---

Dim client As New WebClient()
client.DownloadFile("http://example.com/yourfile.png", "yourfile.png")

---

Since it assumes HTTP, it strips the headers for you.

It's a little more work to do so with HttpClient, but you can do more of the configuration yourself. It's a little weird because it's very heavily Task-based, I'm pretty sure you need at least VS 2013 to use this (and the syntax might need tweaking):

Code:

---

Dim client As New HttpClient()
Using response = Await client.GetAsync("http://example.com/yourfile.png")
    Using (output As New FileStream("yourfile.png", FileMode.Create))
        Await response.CopyToAsync(output)
    End Using
End Using

---

Again, since it assumes HTTP it strips the headers for you. It's more obvious how to set up cookies and other details for this type than it was for WebClient.

With HttpWebRequest, you get a lot more control over all the details, and unfortunately that means you HAVE to set them up yourself. Its abstractions for working with files aren't quite as nice, but are still nicer than having to parse HTTP yourself:

Code:

---

Using request = CType(WebRequest.Create("http://example.com/yourfile.png"), HttpWebRequest)
    request.Method = "GET"
    Dim response = CType(request.GetResponse(), HttpWebResponse)
    Using output As New FileStream("yourfile.png", FileMode.Create)
        Using responseStream = response.GetResponseStream()
            responseStream.CopyTo(output)
        End Using
    End Using
End Using

---

Next up the list is TcpClient/UdpClient. At that point, you have to create/parse HTTP headers yourself, and I don't believe it's worth it. It'd take 10-15 lines of example code just to send the request.

Note that if for some reason you HAVE to save this .png file as .jpg, you need to do a little more work. That involves downloading the data for the .png, loading it into memory as a Bitmap, then re-saving it using JPEG encoding. I don't think that's worth it, either, but you may have some technical reason.

---

That's a Great Explanation.

Ok Let Me let you know the Reason why I'm comfortable to use Socket though it has complexity.

There is an online store which provides free products at a certain time/hours. So, at that precious moment, it's hard to browse that site through default browser due to huge traffic. So I think Socket is best for it.

Do you think httpWebRequest is quite fast as like socket to proceed? I need to send a large number of Requests frequwntly to confirm the order. One more thing I have to manage Cookies.

I still find it a little dubious.

The thing that makes the site behave slowly is not your computer. The problem is their servers cannot handle the volume of traffic they're receiving, or at least that the volume is creating problems. There's not a lot you can do on your end, though requesting JUST the specific image instead of an entire page might help.

I don't think there's anything about the classes on your end that is going to have an impact. Managing cookies is possible with each type, but it gets harder or easier depending on which class you use. The WebRequest/Response types have the most obvious way to mess with cookies, but I'm pretty sure HttpClient and WebClient have ways too.

Thanks. I need to know few more things. According to your Explanation, Now I'm using httpWebRequest. All over its fine.

I need frequently Request until getting response that is why I'm using Timer to Serialize Tasks. Is it valid way?