Domain Soketleri ve Internet Soketleri
Yüklə 181,98 Kb. Pdf görüntüsü
|
- Bu səhifədəki naviqasiya:
- 1.1. UNIX Domain Soketleri 1.2. Internet Soketleri 1.3. Domain Soketleri ve Internet Soketleri
- 2.TCP/IP Protokolü
| İçindekiler 1. Kavramlar 1.1. UNIX Domain Soketleri 1.2. 1.3. Domain Soketleri ve Internet Soketleri 2. TCP/IP Protokolü 2.1. Ağ Erişim Katmanı 2.2. Ağ Katmanı 2.3. Taşıma Katmanı 2.4. Uygulama Katmanı 3. Uygulamadaki Temel Prensipler 3.1. Soket Türleri 3.2. Veri Dönüşümleri 3.3. Sistem Çağrıları 4. Sunucu Soket Programı 4.1. Sistem Çağrılarının Kullanımı 4.2. sunucu.c 5. İstemci Soket Programı 6. Gelişmiş G/Ç 6.1. Bloksuz G/Ç 6.2. select() 7. Sık Sorulan Sorular 8. Belge Tarihçesi 1.Kavramlar Soketler, aynı veya farklı hostlar üzerindeki süreçlerin haberleşmesini sağlayan bir haberleşme (interprocess communication) yöntemidir. Soket, soyut bir tanımla haberleşme uç noktalarıdır. POSIX'in sağladığı programlama API'si sayesinde programcı soketlere yazarken veya okurken yine write(), read() gibi sistem çağrılarını kullanabilir.
açık olabilir. Soketleri birbirinden ayırt etmek ve istemciyi sunucudaki uygun program ile buluşturmak için her soket programın PORT denilen bir numarası vardır. Örneğin FTP protokolünün port numarası 21, Telnet sunucunun port numarası ise 23'tür. Standart servislerin port numaraları /etc/services dosyasında tanımlıdır. 1-1024 arasındaki portlar yalnız root tarafından kullanılabilir, normal kullanıcılar bu portları bind edemezler. IP Numarası: TCP/IP protokolü hostları, sadece kendisine ait olan bir IP numarası ile tanımlar. Bilgisayarlar birbiri ile IP numarasını kullanarak haberleşirler. Bir istemci soket program, önce IP numarasını kullanarak sunucunun bulunduğu bilgisayara, sonra PORT numarasını kullanarak hizmet istediği sunucu program ile temasa geçer. IPV4 standardına göre IP'ler 192.168.1.10 gibi [0- 255].[0-255].[0-255].[0-255] formatına sahiptir. IPV6 standartı 128bit adres kullanır.
protokole aktarır. Buna encapsulation (sarmalama) denir. Karşı tarafta paket açılırken yine her katman kendisi ile ilgili başlığı açar. Örneğin fiziksel katman (mesela ethernet aygıtı) gönderen
sistemin fiziksel katmanının eklediği başlığı açar. Zaten diğer başlıkları yorumlayamaz. Aşağıda sarmalanmış bir paket görülmektedir. +----------------------+ | Ethernet | |+--------------------+| || IP || ||+------------------+|| ||| UDP ||| |||+----------------+||| |||| DNS |||| ||||+--------------+|||| ||||| Veri ||||| ||||+--------------+|||| |||+----------------+||| ||+------------------+|| |+--------------------+| +----------------------+
Aşağıdaki mail, FreeBSD core team üyesi Robert Watson tarafından gönderilmiştir.Yararlı bulduğum için aynen ekliyorum.Mail, UNIX domain soketleri ve internet soketlerinin karşılaştırılması hakkındadır. On Fri, 25 Feb 2005, Baris Simsek wrote: > What are the differences between impelementations of them at kernel level? There are a few differences that might be of interest, in addition to the already pointed out difference that if you start out using IP sockets, you don't have to migrate to them later when you want inter-machine connectivity: - UNIX domain sockets use the file system as the address name space. This means you can use UNIX file permissions to control access to communicate with them. I.e., you can limit what other processes can connect to the daemon -- maybe one user can, but the web server can't, or the like. With IP sockets, the ability to connect to your daemon is exposed off the current system, so additional steps may have to be taken for security. On the other hand, you get network transparency. With UNIX domain sockets, you can actually retrieve the credential of the process that created the remote socket, and use that for access control also, which can be quite convenient on multi-user systems. - IP sockets over localhost are basically looped back network on-the-wire IP. There is intentionally "no special knowledge" of the fact that the connection is to the same system, so no effort is made to bypass the normal IP stack mechanisms for performance reasons. For example, transmission over TCP will always involve two context switches to get to the remote socket, as you have to switch through the netisr, which occurs following the "loopback" of the packet through the synthetic
loopback interface. Likewise, you get all the overhead of ACKs, TCP flow control, encapsulation/decapsulation, etc. Routing will be performed in order to decide if the packets go to the localhost. Large sends will have to be broken down into MTU-size datagrams, which also adds overhead for large writes. It's really TCP, it just goes over a loopback interface by virtue of a special address, or discovering that the address requested is served locally rather than over an ethernet (etc). - UNIX domain sockets have explicit knowledge that they're executing on the same system. They avoid the extra context switch through the netisr, and a sending thread will write the stream or datagrams directly into the receiving socket buffer. No checksums are calculated, no headers are inserted, no routing is performed, etc. Because they have access to the remote socket buffer, they can also directly provide feedback to the sender when it is filling, or more importantly, emptying, rather than having the added overhead of explicit acknowledgement and window changes. The one piece of functionality that UNIX domain sockets don't provide that TCP does is out-of-band data. In practice, this is an issue for almost noone. In general, the argument for implementing over TCP is that it gives you location independence and immediate portability -- you can move the client or the daemon, update an address, and it will "just work". The sockets layer provides a reasonable abstraction of communications services, so it's not hard to write an application so that the connection/binding portion knows about TCP and UNIX domain sockets, and all the rest just uses the socket it's given. So if you're looking for performance locally, I think UNIX domain sockets probably best meet your need. Many people will code to TCP anyway because performance is often less critical, and the network portability benefit is substantial. Right now, the UNIX domain socket code is covered by a subsystem lock; I have a version that used more fine-grain locking, but have not yet evaluated the performance impact of those changes. I've you're running in an SMP environment with four processors, it could be that those changes might positively impact performance, so if you'd like the patches, let me know. Right now they're on my schedule to start testing, but not on the path for inclusion in FreeBSD 5.4. The primary benefit of greater granularity would be if you had many pairs of threads/processes communicating across processors using UNIX domain sockets, and as a result there was substantial contention on the UNIX domain socket subsystem lock. The patches don't increase the cost of normal send/receive operations, but due add extra mutex operations in the listen/accept/connect/bind paths. Robert N M Watson 2.TCP/IP Protokolü TCP/IP, "Transaction Control Protocol and Internet Protocol" için bir kısaltmadır. TCP/IP, DARPA(Defense Advanced Research Projects Agency) projesi olarak 1970'lerde Amerika'daki bazı devlet kurumlarını birbirine bağlamak amacı ile geliştirildi. Daha sonra BSD(Berkeley Software Distribution) UNIX'e eklenerek uygulama alanı buldu. TCP/IP'nin içerdiği protokollerin tanımları RFC(Request For Comments)'lerde yapılmıştır. RFC'lere ulaşmak için: http://www.faqs.org/rfcs/ TCP/IP 4 katmanlı bir modeldir: 1. Uygulama Katmanı 2. Taşıma Katmanı 3. Internet Katmanı 4. Ağ Erişim Katmanı. Her bir katman OSI modelindeki bir veya daha fazla katmanın işlevine sahiptir. 1982'de BSD UNIX ile TCP/IP uygulamaları geliştirildi. Yüklə 181,98 Kb. Dostları ilə paylaş:
|