Existe-t-il des différences majeures lorsque nous parlons de "programmation socket" par rapport à la "programmation réseau"?
Y a-t-il des sujets qui couvrent la "programmation réseau" mais pas la "programmation socket"?
Existe-t-il des différences majeures lorsque nous parlons de "programmation socket" par rapport à la "programmation réseau"?
Y a-t-il des sujets qui couvrent la "programmation réseau" mais pas la "programmation socket"?
Réponses:
La programmation par socket (au moins comme le terme est normalement utilisé) est la programmation vers une API réseau spécifique. Les sockets prennent en charge les protocoles basés sur IP (principalement TCP et UDP) 1 .
La programmation réseau peut être effectuée à l'aide de diverses autres API. Windows possède un certain nombre d'API indépendantes du protocole telles que les fonctions WNet * et Net *. Les versions plus anciennes de Windows utilisaient également NetBIOS / NetBEUI (NetBIOS End User Interface), et la plupart des IPX / SPX (un ancien protocole Netware) étaient les plus pris en charge (et le font probablement toujours).
La programmation réseau la plus courante, cependant, se fait soit en utilisant des sockets directement, soit en utilisant diverses autres couches au-dessus des sockets (par exemple, beaucoup se fait sur HTTP, qui est normalement implémenté avec TCP sur sockets). TCP / IP et UDP / IP (ainsi qu'un certain nombre d'autres protocoles basés sur IP) se font principalement via l'interface des sockets. En théorie, d'autres interfaces de programmation pourraient être utilisées, mais dans la pratique, les sockets semblent suffisantes, il n'y a donc pas beaucoup d'intérêt à le remplacer. Je dois cependant mentionner que les sockets Windows (WinSock) ont pas mal d'extensions plus ou moins uniques à Windows. Je suppose qu'il est ouvert à certains arguments si le code qui utilise ces extensions se qualifie vraiment comme du code "sockets" ou non - ce sont des extensions basées sur les mêmes concepts, mais le code qui les utilise n'est pas ' t normalement portable sur d'autres systèmes. Je suppose que si cela se qualifie de "sockets" ou non, cela dépend principalement de savoir si vous considérez les sockets plutôt comme un concept, ou un ensemble très spécifique de fonctions, de paramètres, etc.
Modifier (en réponse au commentaire):
Il est un peu difficile de dire si «connaître les sockets» implique de tout savoir sur TCP et UDP. Prenons un petit élément: un programme de démonstration typique pour les sockets crée un programme de chat client / serveur. Le client se connecte au serveur et lorsque l'utilisateur sur un client tape quelque chose, il est transféré aux autres clients connectés au même serveur. Chaque client affiche ce qui vient du serveur et permet à l'utilisateur de taper des messages à envoyer aux autres clients.
En même temps, réfléchissez à ce qu'implique un "vrai" programme de chat comme AIM, Windows Messenger, iChat, etc. Pour gérer non seulement le texte, mais la voix, la vidéo, les transferts de fichiers, les groupes, les listes, etc., un programme typique implique probablement une douzaine de normes différentes, y compris des choses telles que SIP, STUN, TURN, RTCP, RTP, XAMPP, mDNS, etc. .
IMO, quelqu'un qui "connaît les sockets" devrait être en mesure de coder le premier programme de chat (niveau démo, texte uniquement) en quelques heures sans passer beaucoup de temps dans les fichiers d'aide (et autres) à faire des recherches. À moins qu'ils ne revendiquent au moins une certaine expérience antérieure de travail sur un "vrai" programme de chat, je ne m'attendrais pas à ce qu'ils sachent même quels RFC / normes s'appliquent à de telles choses.
La même chose s'applique en général: étant donné le nombre de RFC (et diverses autres normes) qui s'appliquent à toutes les différentes choses que les gens font sur les réseaux, il est déraisonnable de s'attendre à ce que quelqu'un les ait tous mémorisés. Néanmoins, si vous avez un ensemble d'exigences pour quelque chose que vous vous attendez à ce que les gens soient capables de gérer facilement dans un programme "local", l'ajout de "sur le réseau" comme une exigence ne devrait normalement pas ajouter énormément de difficulté (bien que traitant de problèmes comme la latence du réseau).
1 Les sockets sous Unix prennent également en charge les sockets de la famille Unix, mais ceux-ci sont (au moins normalement) utilisés pour l'IPC intra-machine, pas pour la mise en réseau. Il existe également des dizaines d'autres protocoles pour des choses telles que la gestion des routeurs que les sockets ne prennent pas vraiment en charge (au-delà des sockets bruts vous permettant de créer et d'envoyer des paquets arbitraires).
la "programmation réseau" nécessitera une technologie de mise en réseau - par exemple, RPC. Les sockets (vous entendez probablement des sockets BSD) sont un exemple de cette technologie. La "programmation par socket" est donc un sous-ensemble de la "programmation réseau".
Oui, il est vrai que la programmation réseau nécessite une technologie de mise en réseau alors que la programmation socket est un sous-ensemble de la programmation réseau. La programmation réseau la plus courante se fait soit en utilisant des sockets directement, soit en utilisant diverses autres couches au-dessus des sockets.