The API changes should provide both source and binary (1)for programswritten to the original API. That is, existing program binaries should continueto operate when run on a system supporting the new API. In addition, existing(2) that are re-compiled and run on a system supporting the new API shouldcontinue to operate. Simply put, the API （3）for multicastreceivers that specify source filters should not break existing programs. Thechanges to the API should be as small as possible in order to simplify the taskof converting existing (4 ) receiver applications to use source filters.Applications should be able to detect when the new（5） filter APIsare unavailable (e.g., calls fail with the ENOTSUPP error) and react gracefully(e.g., revert to old non-source-filter API or display a meaningful errormessage to the user).

（1）A. capability     

B. compatibility   

C. labiality     

D. reliability

（2）A. systems      

B. programs      

C. applications  

D. users

（3）A. connections    

B. changes       

C. resources    

D. considerations

（4）A. multicast     

B. unicast       

C. broadcast    

D. anycast

（5）A. resource     

B. state         

C. destination   

D. source