|
softwarejaeger wrote: And please... no answers like "use TCP instead of UDP"
Why not?
What you are doing is to try and run a TCP-like communication link using UDP. Unless your datagrams are totally independent then you need to implement some mechanism for re-assembling all the parts into the whole. This means you need to check each datagram as it is received, and if you have not received one or more in the sequence, you should check which are missing and request a retransmit from the sender. The actual sending interval is irrelevant as UDP merely transmits each datagram but does not check (or care) whether it is safely received or not, thus even if you figure out the optimum sending interval it still does not guarantee that i) the message will be safely delivered, or ii) the message will be delivered in the correct sequence.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Because i need to use UDP (that's it!)
So... what i've done? I exactly realized that, what you told me. I check the correctness of the package, i check if the previous package is failing (and ask the other client for that package) and to "ii)" because that's why i have a sequential number in each data package.
That isn't right, that the sending interval is irrelevant, because if i send data over the internet (behind two NAT) slowly, i get all data, but if i do this very fast, i have a high loss-rate, which i want to avoid. So i need to calculate the "correct" and stable data-sending rate.
|
|
|
|
|
softwarejaeger wrote: So i need to calculate the "correct" and stable data-sending rate.
Not an easy thing to do, since it depends on other factors, such as traffic density on the network, network reliability etc. I think you may find that these are the sort of things that need to be recalculated on a regular basis for optimum performance. Which is why most people will just say "use TCP, that's what it is designed for". However if you are able to create a better performing protocol using UDP you may be on your way to fame and fortune.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
softwarejaeger wrote: Because i need to use UDP (that's it!)
So reimplement TCP using UDP.
There is a reason for the functionality that exists in TCP. You can implement most of it via UDP.
Read the TCP spec and read up on the algorithms in it.
And one advantage there is that since the algorithms are self correcting there is no fixed interval.
|
|
|
|
|
Wow! You're expecting a lot for a protocol that doesn't guarantee delivery of packets at all, and get this, doesn't even guarantee that the packets will arrive in the order that you sent them! YES, it's entirely possible for packets to arrive in the wrong order!
Believe it or not, what you're trying to do is rewrite TCP yourself.
|
|
|
|
|
Errrrr, you don't want to use TCP, so you want to implement a network protocol which works just like TCP does... Well, I don't get the point. I don't know if you understand the difference between UDP and TCP, so let me give you some advices:
1. UDP does not provide any control over the order in which the datagrams will arrive to their destination. You should check for this in an upper level.
2. UDP does not provide any control if a datagram is duplicated. You should check for this in an upper level.
3. UDP does not provide any control if a datagram is missing. You should check for this in an upper level.
4. UDP does not provide any control if a datagram is corrupted. You should check for this in an upper level.
If you want to use UDP for a transmission that should work as if you were using TCP, chances are:
a) Use TCP (sorry, I know you don't want, but this is just what I would do)
b) Implement a new protocol which allow yo to:
1. Have control over the order in which the datagrams will arrive to their destination.
2. Know if a datagram is duplicated.
3. Know if a datagram is missing.
4. Know if a datagram is corrupted.
In other words, implement a variation of TCP protocol...
As I have seen in your post, it seems that you have only thought about the order of the datagrams and the missing datagrams, so you've got half of the job so far: you still have to check for duplicate and corrupted datagrams.
Edit: Sorry, I did not see the previous answer before writing this "Bible". Can we know why do you have to use UDP and cannot use any other protocol?
|
|
|
|
|
Well.. so for everyone, why i'm using UDP instead of TCP.
First point: NAT (I need to make whole punching, because i need a P2P Connection)
Second point: Latency (In a few cases, i doesn't need the whole "TCP" Features, i just want to send little messages)
My protocol is doing exactly that and can all of kind like check for sequence, check for corrupcy and so on. But... i want the best performance and network bandwith load. So i need to calculate, how many packages i'm able to send, to not get a huge of requests back again.
|
|
|
|
|
Oh, ok, I think I understand now. You mean you still have to implement some congestion control mechanism, don't you?
I have never done this, but there are several possible approaches. This article[^] might give you a point of start. You might want to have a look at SCTP protocol as well. It is not natively supported on Windows but there is a Windows driver here[^] which you could use.
|
|
|
|
|
The calculation you want isn't going to help because conditition change moment to moment. The limit that you calculate is no good the second you start sending packets and can change depending on network factors between to the endpoints.
|
|
|
|
|
I've done things like this with much lower level protocols. Typically I do it with ACK messages, so you send one UDP frame, then wait for the receiver to ACK before you send the next. It works well if you don't have time sensitive stuff like sending video. If you have to optimize due to lag or timing constraints, you could frame your own message protocol inside the UDP frame that would include a sequence number. That method will allow the receiver to send NACK messages (Negative ACK if you didn't know) on messages that it didn't receive. I think you'll definitely have to ACK messages in some way weather it's on every message or missed ones.
Hope it helps.
EDIT:
After re-reading your original post, maybe your protocol includes ACK/NACK. One other thing you could do is try to optimize the size of the frame you're sending so that it fills as much of the frame as possible. Look up Minimum Transmission Units or something like that. You may also want to look at waiting for the order of arrival. Your sender just sends and sends, and the receiver can ask for specific frame numbers. You could eliminate any kind of artificial turnaround wait times. It would be up to the sender to buffer and sequence packets in some way that is saved or can be calculated for retries, and up to your receiver to be able to continue to receive in spite of out of order data.
"Simplicity carried to the extreme becomes elegance."
-Jon Franklin
|
|
|
|
|
carbon_golem wrote: That method will allow the receiver to send NACK messages (Negative ACK if you didn't know) on messages that it didn't receive.
And how exactly is it going to make that determination?
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
You have to be aware of the sequence number. It will be up to the receiver to keep track of what it has and to identify missing frames.
1,2,3,4,5,6, 7-MISSING ,8,9,10,11, 12-MISSING... etc.
A quick scan through the list and you'll find the missing frames (7 and 12). The receiver would have to request that those two be resent. If all frames were ACK'd the sender is waiting for a confirmation and is waiting to send the next one in line. I've worked with systems that function like this, and the ACK-on-every-message is woefully slow on high latency networks. You just have to send and hope it gets there, and put in provisions to resend frames later on down the road.
You could also pre-parse the data that is to be sent and create a manifest of sorts that is sent first. If you know exactly what to expect in a data transfer the problem gets a little easier I think.
"Simplicity carried to the extreme becomes elegance."
-Jon Franklin
|
|
|
|
|
Yes, but the receiver does not know they are missing until the next one arrives. It then has to go through a retransmit sequence to get that message, which may, or may not be delivered. Running a protocol like this defeats the purpose of UDP and also adds a lot of host processing overhead which TCP handles at a much lower level. I think the OP is making a rod for his own back in following this route.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
You're exactly right. Why UDP is insisted upon is baffling.
"Simplicity carried to the extreme becomes elegance."
-Jon Franklin
|
|
|
|
|
for about box display with different languages?
Чесноков
|
|
|
|
|
Why not just consider the values in the dialog to be like any other localisable label, and store the different values like you do any other control? The values used for attribute constructors need to be compile-time constants, so the only way to localize the attributes (unless they support accessing a localisable resource, like the validation attributes) would be to have several different builds, one for each language, and change the value each time.
|
|
|
|
|
|
It is possible to test if '.Text' is found at the end of DictionaryEntry element in when parsing ResXResourceReader element to extract text for localization.
But how to process string resources in Resources.resx? They are not allowed to be named with .Text at the end.
Is there some generic rule to extract .Text resources from GUI and string resources from Resources.resx?
Чесноков
|
|
|
|
|
Hello,
I made a web service making changes to a pdf for this, it takes as input : the PDF file encoded in base 64 and the output : pdf file amended encoded as base 64.
I have the exception below:
The formatter threw an exception while trying to deserialize the message: An error occurred while trying to deserialize parameter http://tempuri.org/:webservice_64Response. The InnerException message was "An error occurred during deserialization of the object type webservice_consommation.ServiceReference1.webservice_64ResponseBody. Exceeding the quota limit for the length of string content (8192) when reading XML data. This quota may be increased by modifying the property MaxStringContentLength XmlDictionaryReaderQuotas the object used when creating the XML reader. Line 1, position 29421. . For more information, see InnerException.
Can we increase the quota?
Thank you very much.
|
|
|
|
|
You asked this question just below. Don't repost.
|
|
|
|
|
Hello,
I use this method to encode in base 64 :
[WebMethod]
public string EncodeFileTo64Digits(string File_Path_input)
{
string base64;
using (FileStream fs = new FileStream(File_Path_input, FileMode.Open, FileAccess.Read))
{
string ext;
byte[] data = new byte[fs.Length];
fs.Read(data, 0, data.Length);
base64 = Convert.ToBase64String(data);
ext = base64;
return ext;
}
}
Thank you verry mutch for hlep me to resolve this great problem.
|
|
|
|
|
You seem to be intent in persisting in this behaviour. Instead of adding this snippet here, you should amend the question below because that contains the original question, along with answers that have already been given. I will say that if your intent is to download the file, you should return a byte[] and not an encoded string.
|
|
|
|
|
Hello,
I am sorry, but i must return the encoded base 64 file, i consume my web service like this :
ServiceReference2.TEST_ServicesSoapClient ff = new encode_consommation.ServiceReference2.TEST_ServicesSoapClient();
string rr = ff.transformPDF("fqrgfqfsgfdsgfg.....");
I checked the all execution step, so they stops at the return of my string.
Thank you verry mutch.
modified on Monday, December 27, 2010 4:37 AM
|
|
|
|
|
You still haven't learned: no-one is going to answer a question here as yip have re-posted. Edit your original question (which, BTW, missed all the vital information you have posted since).
|
|
|
|
|
I have popcorn, and I'm watching with great interest...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
