|
This icon is the one assigned to the Form.Icon property: documentation[^].
|
|
|
|
|
Thanks for the answers and suggestions 
|
|
|
|
|
I am working on a Png encoder software . This software has a requirement that it should generate a png file without the PLTE(palette) chunk , so I want to programmatically delete the "palette chunk" using C#.Net.
Anybody out here knows how it can be done using the dotnet framework?
|
|
|
|
|
Why don't you just not encode it as paletted in the first place?
Anyway if you're going to forcefully remove the PLTE chunk (which is pretty easy), beware that that makes the PNG invalid (indexed PNG's need a PLTE chunk).
|
|
|
|
|
Yes right ... Deleting palette chunk will make the PNG invalid i know that .. but thats the requirement.
You said that the deleting palette chunk is easy. How do i implement that in C#.Net??
Kindly reply.
|
|
|
|
|
Ok that's odd, but ok. This is what I would do.
Read the file back with a BinaryReader. Beware that integers in PNG are stored big-endian, so if you need their integer value you have to byte-reverse it (there is of course no good reason to reverse the FourCC's, just reverse the constants you test them against).
Write all chunks to an other stream unless the FourCC of the chunk is PLTE (FourCC's can not be read as strings because they are not strings in the way BinaryReader wants them, just read an int32 and test against 0x45544C50 (ETLP in ASCII) - the other FourCC's are not relevant, just write anything "unknown" to the destination stream).
|
|
|
|
|
You'll have to work with the file format directly. The .Net API won't let you create an indexed image without the colour table, because it's invalid.
|
|
|
|
|
I have created a .png file from say a bmp using the Image.Save() call. Now I want to delete the PLTE chunk from the .png file created , how do I do it??
Best Regards
|
|
|
|
|
Read the file using file reading tools (e.g. FileStream), find the PLTE chunk and rewrite the file not including it. This will require you to understand the PNG file format so you can recognise the part you want to process differently.
|
|
|
|
|
hello guys... I have this database application on <b>machine 1</b>. Now I want to save some of the records on <b>machine 2</b>, in sql server. This is client-server architecture. Client is not the problem here, it will be merely a record like
ID - Name - StartTime - EndTime
--- ------ --------- --------
The problem is server. I dont know what to implement on machine 2 (the server). Which of the following should I use
- WCF
- socket programming
- or remotely access the sql server on machine 2.
I am just confused whats the best choice?
|
|
|
|
|
Depends.
Will all the machines always (forever) be on the same network behind the firewall? If so, you can just use ADO.NET or whatever and connect directly to both SQL servers.
Will there be a lot of data transferred?
I'd DEFINITELY avoid WCF because its very slow and network traffic is very large (relative to the real data) because its all SOAP & WSDL.
If you need to access the server from outside the firewall, transfer a lot of data, etc. I'd go with the socket server middle man approach. Thats really the most scalable, but also the most work to get going  .
|
|
|
|
|
SledgeHammer01 wrote: I'd DEFINITELY avoid WCF because its very slow and network traffic is very large
(relative to the real data) because its all SOAP & WSDL.
Errm, this is only true if you don't use something like TcpBinding. WCF is transport agnostic.
|
|
|
|
|
Pete O'Hanlon wrote: Errm, this is only true if you don't use something like TcpBinding. WCF is
transport agnostic.
Ok, and how many clients can you handle with TcpBinding on a single server? Is the TcpBinding fully binary and stripped of all XML tags?
Also, the OP wanted push notification which WCF doesn't support as far as I know. Or does it?
So my original response of an IOCP TCP/IP server is the best answer for his scenario regardless of my slight misinformation on WCF . Multiple clients polling the database directly every second is a poor design.
|
|
|
|
|
SledgeHammer01 wrote: Ok, and how many clients can you handle with TcpBinding on a single server?
Well, we have one app which is currently handling about 5K clients (granted not push), using TCP. I didn't see anything in the OP that suggests that he has any need for that type of scale.
SledgeHammer01 wrote: Is the TcpBinding fully binary and stripped of all XML tags?
Yes.
|
|
|
|
|
Pete O'Hanlon wrote: I didn't see anything in the OP that suggests that he has any need for that type
of scale.
Yes, OP confessed he only has a need for about 5 clients. Carving stone tablets and shipping them via carrier pigeon would work at that scale.
Pete O'Hanlon wrote: Well, we have one app which is currently handling about 5K clients (granted not
push), using TCP. I didn't see anything in the OP that suggests that he has any
need for that type of scale.
Cool. Yes, that is what I've seen on google as well. Something in the 3k to 5k range.
If you want something that'll do 10k+ clients bi-directional though, as far as I know, only TCP/IP w/ IOCP can handle that.
Yeah, but 5 != 10,000 .
|
|
|
|
|
SledgeHammer01 wrote: I'd DEFINITELY avoid WCF because its very slow and network traffic is very large
(relative to the real data) because its all SOAP & WSDL.
There is overhead regardless of the transfer mechanism.
And if there is actual concern about the traffic size and message throughput then a wide range of conderations come into play. And if that is really a concern then myself I would go with import files and moving them via file transfer mechanism.
But excluding exremely high volume systems on a modern data center setup any WCF implementation is going to be sufficient.
|
|
|
|
|
I've never tested it on WCF myself, but I did a quick google search and ONE guy claimed he wrote a WCF service that could handle 7000 "concurrent clients". Most other links I found are claiming closer to around 3000 to 5000 for a "real" service. The 7000 client guy had a very light weight sample.
If you have < 100 clients or whatever, pretty much anything will work. Maybe even at 1000 clients anything will work. Even if its all the way up to 5000 on a real service, you do realize that is very few clients in the internet scheme of things, right?
I did ask the guy how many clients he had...
But regardless of that fact... WCF doesn't support push.
|
|
|
|
|
SledgeHammer01 wrote: But regardless of that fact... WCF doesn't support push.
So, you can't do any form of push with WCF at all[^]?
|
|
|
|
|
Ah, didn't know you could do that .
|
|
|
|
|
|
SledgeHammer01 wrote: Even if its all the way up to 5000 on a real service, you do realize that is very few clients in the internet scheme of things, right?
Not sure what you mean.
However a site that has 5000 simultaneous clients would be a site with very high traffic.
And if the OP wants to do a machine to machine database transfer that involves 5000 simultaneous clients then I suspect a flawed design and/or flawed architecture. Not to mention a flawed question.
SledgeHammer01 wrote: WCF doesn't support push.
And that matters why? Do you think that most client/server applications should be designed with push? Do you think that serves the OPs goal?
|
|
|
|
|
jschell wrote: However a site that has 5000 simultaneous clients would be a site with very high
traffic.
Well, CodeProject has 8.4M members... throw out the spammers, etc and consider that it is a niche site.... according to the stats there are 38k users online at this typing.
Games will have more then 5000 simultaneous clients easily.
Anyways, this is all a moot point since OP says he will have only 5 .
jschell wrote: And that matters why? Do you think that most client/server applications should
be designed with push? Do you think that serves the OPs goal?
I stand corrected on that it doesn't support push as Pete posted an article showing callbacks.
But yes, the OP would be better off with a push design vs. polling every second which was his original issue.
He was polling the database every second and complaining of jerky refreshes. A push vs. poll design solves that problem.
|
|
|
|
|
SledgeHammer01 wrote: Well, CodeProject has 8.4M members... throw out the spammers, etc and consider that it is a niche site.... according to the stats there are 38k users online at this typing.
First this site uses http, so the fact that the is 38k sessions has nothing to do with how many connections there are at one time.
Second I am sure google and facebook have even more.
However extrapolating that every or even most websites will have that much traffic would easily exceed the population of the planet. So most web sites will not experience that much traffic. Ever.
SledgeHammer01 wrote: He was polling the database every second and complaining of jerky refreshes. A push vs. poll design solves that problem.
I can't find that post. And if it was made...
1. It is a GUI problem not a data transport problem.
2. Humans can't react in one second so the requirement is pointless.
3. All databases that I know of can easily handle polling with 5 clients with a one second poll rate.
|
|
|
|
|
jschell wrote: However extrapolating that every or even most websites will have that much
traffic would easily exceed the population of the planet. So most web sites will
not experience that much traffic. Ever.
Sounds like you really need to get out into the real world if you think 5000 simultaneous connections is a lot. Game servers have WAY more. Brokerages that offer real-time stock tickers have WAY more. Those are some REAL WORLD examples for you since I know you have a really difficult / impossible time wrapping your brain around "hypothetical concepts" 
Anyways, that's not the point. The OP clearly stated he would have 5 low bandwidth connections later on, so he doesn't need a high bandwidth, scaling solution.
jschell wrote: I can't find that post. And if it was made...
That was his first post.
jschell wrote: 1. It is a GUI problem not a data transport problem.
False. Again. ADO.NET out of the box closes the connection after every query / stored proc call and uses TDS over TCP/IP. Open + Connect + Execute Query + Merge results + close connection is actually a relatively expensive call. If you are doing this in a background thread, it wouldn't make the GUI jerky per say, but it would affect performance. If you are doing it in the foreground thread, thats a GUI issue. However, you can't update the GUI from a background thread directly (without invoke), so that'll affect the GUI performance.
jschell wrote: 2. Humans can't react in one second so the requirement is pointless.
You just don't like real requirements do you? Reading your posts and playing arm chair psychiatrist, I think I have finally figured out your problem. You have spent too many years implementing "business requirements" at business oriented companies that don't care about performance. Thats cool. I work at a company right now where the boss doesn't care about performance. He doesn't care if it takes 1 minute to process a widget vs. 1 second. I mean, sure he is completely disregarding the fact that we have to process BILLIONS of widgets and that 1ms per widget is 277 HOURS per billion widgets, but thats neither here nor there.
As indicated above, game servers & stock tickers are REAL WORLD examples of stuff that needs to happen quickly.
Is that relevant to the OP? No, not really.
jschell wrote: All databases that I know of can easily handle polling with 5 clients with a one
second poll rate.
How weird. My boss built a service that polls a hefty Windows 2008 + SQL 2008 box on a single connection / single thread and the box can barely keep up.
|
|
|
|
|
SledgeHammer01 wrote: Sounds like you really need to get out into the real world if you think 5000
simultaneous connections is a lot. Game servers have WAY more. Brokerages that
offer real-time stock tickers have WAY more. Those are some REAL WORLD examples
for you since I know you have a really difficult / impossible time wrapping your
brain around "hypothetical concepts"
And what is the percentage of websites that generate those numbers versus the total number of websites in the world?
SledgeHammer01 wrote: That was his first post.
First post at this time says nothing at all about "jerky refreshes".
SledgeHammer01 wrote: False. Again. ADO.NET out of the box closes ...
The phrase "jerky refreshes" suggests a GUI display problem to me.
SledgeHammer01 wrote: You just don't like real requirements do you? Reading your posts and
playing arm chair psychiatrist, I think I have finally figured out your problem.
You have spent too many years implementing "business requirements" at business
oriented companies that don't care about performance.
Current server that I wrote and support has a measured rate based on realistic traffic of 100 TPS (Transactions Per Second) for a single box, with a burst rate of 600 over 3 seconds. The expected volume for the largest servable market business segment for that market is 2000 TPS seconds which translates to 20 boxes. That server currently runs in two geographical distinct redundant data centers supporting remote and local and remote failover.
So I would say that your 'guess' is wrong.
SledgeHammer01 wrote: My boss built a service that polls a hefty Windows 2008 + SQL 2008 box on a
single connection / single thread and the box can barely keep up.
I worked at a company where the VP would write SQL queries that would shut down the database and 200+ call center workers in the process. But then the queries were poorly written.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
