ADC Home > Reference Library > Technical Notes > Legacy Documents > Networking >
Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.
Current information on this Reference Library topic can be found here:
|
Datagram Delivery Protocol (DDP) header checksum fieldDate Written: 4/2/91 Last reviewed: 6/14/93 Does the Macintosh client pay attention to and validate Datagram Delivery Protocol (DDP) checksums within long DDP packets received? DDP is a client of the AppleTalk Transaction Protocol (ATP), which is a client of the AppleTalk Session Protocol (ASP) and AppleTalk Filing Protocol (AFP). DDP is told by the entity for whom it is a client whether it should use checksumming. For performance reasons, our version of ATP does not specify that DDP use the checksum. Both AppleShare and the AppleShare client are out of the loop; neither can specify whether or not to use the DDP checksum. The LAP layer performs checksumming, ensuring no on-the-wire corruption. The only benefit of DDP checksumming is end-to-end corruption detection when the packet has travelled over a malicious router that has validly received a DDP packet on one net, changed the packet, re-computed the LAP checksum, and sent it out on another cable. Because of the performance hit of DDP checksumming and the rarity of such a malicious router, it was decided not to request DDP checksumming. ZIP Query packet zero checksum valueDate Written: 3/3/92 Last reviewed: 6/14/93 Is a zero checksum value indicative of no checksum provided with the Zone Information Protocol (ZIP) packet? True, a zero checksum in any DDP packet with an extended header (including ZIP packets) indicates that a checksum was not performed. See Inside AppleTalk, 2nd Ed. pages 4-17. How to write a DDP read with completion routineDate Written: 2/28/92 Last reviewed: 2/28/92
The PWriteDDP call is nothing like a
Because of the Communication between players in a game on an AT networkDate Written: 12/18/90 Last reviewed: 2/1/91 How can I use the broadcast mode in an AppleTalk DataGram Delivery Protocol (DDP) layer to communicate with the other players of a game that is on a network and not interfere with other network users? The broadcast mode may seem like a solution, but Apple doesn't recommend using broadcast mode. Applications like games generally end up sending LOTS of update packets to other players of the games. If your program broadcasts those packets, then all nodes on your network will be interrupted for every packet sent and that can cause performance problems on every machine on a network. In Apple supplied software, broadcast mode is only used when packets need to be sent to every node on a network. For example, Name Binding Protocol (NBP) Lookup packets are broadcast because the network address is unknown. The following suggestions should help implement communications between players. The DDP protocol layer does not guarantee delivery of packets (the disadvantage), but has very little overhead (the advantage). If you require delivery of all packets and can take a small additional performance hit, you should use the AppleTalk Transaction Protocol (ATP) layer. The DDP type you use must be in the range of $10-$FF. The DDP type you choose to use (in that range) probably won't make a lot of difference unless you define multiple clients to DDP within your socket listener. Packets addressed to your socket will get sent to your socket listener. How you use the type is up to you (as long as you stay out of the reserved range).
You should open a dynamic socket (i.e., use 0 for the socket number and use the
socket number in the range $80-$FE that is returned) with the If you build a table (array) of network addresses from those playing a game, you can use this algorithm to send a packet to each player.
Downloadables
|
|