sorry, msg(0) and (1) are the same message, (1) being a resend of (0).

but you see, the client needs to keep a copy of the message (or at least some limited information), in case the server resends it, so the client knows it's a duplicate, and don't process it twice. That in my opinion is bad and seemed wasteful, overly complicated. That's what I'm trying to avoid.

Also, the message has to store guids of messages as part of the message, to tell which message is which. I don't really want to enforce that in a UPD wrapper. Message number is different in a sense that it's not a real GUID and incures no extra complexity (re-usable GUIDs can be a pain).

I like the straight forward method of reliable, in-sequence data streams. Latency, as I said, should not be a problem for reliable message. If it is, you have a flaw in your system.

It's just my opinion anyway. Also, as you said, data streams avoids flooding the client with constant resends. YOu only have one resend per channel, which is manageable.

Quote:Original post by lightbringer
Sorry, I didn't mean that in a negative way. It is true however that the protocols in question have been around for a long time without tremendous advances. My (unqualified) opinion about that is that we're tied down by legacy infrastructure.

I just wanted to help by pointing out a thread where people smarter than I am discussed at length the issues of named libraries and various methods of home-brew implementation. The good stuff starts halfway down page 2, so oliii don't think I mean to imply anything about your level of competence here.

non taken. It's late, I'm tired, and the head hurts with bitstreams, protocols, wrappers, and to much coffee. I'll have a look at the thread, it looks intresting, but it's 10 pages long! :)

Quote:Original post by cbenoi1
> I want to learn that stuff.

RFC 908 is well-documented and simple enough for implementation.

RFC908 clicky

-cb

Yup. I've got to read all those protocols and standard papers... :/ I'm gonna cry.

Quote:but you see, the client needs to keep a copy of the message (or at least some limited information), in case the server resends it, so the client knows it's a duplicate, and don't process it twice. That in my opinion is bad and seemed wasteful, overly complicated. That's what I'm trying to avoid.

Not really. Each packet sent will have a unique sequential ID. If at any time you recieve a packet with an ID that is equal to or less than the most current packet ID recieved, its a duplicate/late packet and can be disregarded.

You will however need to cache a copy of an early packet until you get all the packets leading up to it.

<Client gets packet 01>
<Client searches buffered list for packets>
<Client gets packet 02>
<Client searches buffered list for packets>
<Client gets packet 03>
<Client searches buffered list for packets>
<Client gets packet 06> (This packet is not directly in sequence past the most current packet ID recieved. So its cached in a buffered list of packets)
<Client searches buffered list for packets>
<Client gets packet 04>
<Client searches buffered list for packets>
<Client gets packet 05>
<Client searches buffered list for packets> (Client finds that a buffered packet with an ID 06 is directly after the most current packet ID recieved, pops it off the list and then processes it like any other packet)
<Client gets packet 07>
<Client searches buffered list for packets>
<etc..>


-=[ Megahertz ]=-

thanks all. I'm 'closing' this :)