|
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
|
|
|
|
|
I guess it wouldn't be worth to answer him in the right thread... He does not read the answers...
|
|
|
|
|
Hello,
I test my web service with soapUI, my methos return the correct encode base 64.
I call the web service correctly ?
|
|
|
|
|
5'd, if only to keep you in the same rep zone as JSOP  !
|
|
|
|
|
 Thanks Keith. Surprisingly enough, I'm not actually in competition with JSOP. He's written far more articles than me so his position would be difficult to assail - what I do want though, is for JSOP and me to be able to beat CG on combined post counts.
|
|
|
|
|
I don't think that will ever happen. CG has far too many hardware and software problems and disputes with Qantas, Telstra, and TicketMaster to complain about, and every couple of weeks, his post count goes up by 1000 or so while he describes his latest travails...
".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
|
|
|
|
|
John Simmons / outlaw programmer wrote: I don't think that will ever happen.
No john, surely your Tag team can beat CG as Pete said. I wish CG will get good things & good net connection soon quickly.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
