اتصال End-to-end

[eshpilen]

End-to-end connectivity یک عنصر اصلی طراحی اینترنت است که به گره های شبکه اجازه میدهد بدون نیازمند بودن به اینکه عناصر واسط شبکه اطلاعات وضعیتی راجع به انتقال را نگهداری کنند بسته های دیتا را به تمام گره های دیگر شبکه بفرستند. این ایده ابتدا در شبکهء CYCLADES توسعه داده و پیاده سازی شد.

مترجم: CYCLADES یک شبکهء کامپیوتری تحقیقاتی فرانسوی بود که ایده های بکار رفته در آن تاثیر بسیاری در طراحی اولیهء اینترنت و پروتکل های آن داشت. CYCLADES خود بعنوان جستجوی جایگزینی برای طراحیARPANET توسعه داده شد.

برای اینترنت این طراحی در مجموعه پروتکل های اینترنت (Internet Protocol Suite) پیاده سازی شده است که عموما TCP/IP نامیده میشود.

گسترش سریع اینترنت و پر شدن آدرسهای IPv4 (نسخهء 4 پروتکل IP) باعث اجبار به تغییراتی در ساختار اولیه ای که برای فضای آدرس IP در ارتباط با اختصاص آدرس و فناوریهای مسیردهی (routing) تصور شده بود شد. بعلاوه، فناوریهایی اختراع شدند که کمک کردند مشکل پر شدن آدرسها بصورت موقتی تخفیف یابد، اما این فناوریها عناصر شبکه ای همچون دستگاههای ترجمهء آدرس شبکه (network address translation) را بوجود آوردند که از اصل end-to-end تبعیت نمیکنند. بدون این خصوصیت، بعضی پروتکل های شبکه به پشتیبانی خاص عناصر شبکه در طول عبور نیاز دارند. این عامل بازدارنده باعث جلوگیری از توسعهء بسیاری از کاربردهای جدید و اغلب تعاملی (interactive)، شامل امنیت (IPsec)، کوچ به IPv6 (تونل زدن IPv6 در داخل IPv4)، اپلیکیشن های peer-to-peer، و بازیهای شبکه ای میشود.

بعضی اوقات بصورت اشتباهی اتصال end-to-end بعنوان وسیله ای برای پیاده سازی امنیت شبکه عمدا شکسته میشود چرا که استفاده از ترجمهء آدرس همچنین فضای مسیردهی را محدود میسازد که به معنای اینست که رایانه های پشت NAT نمیتوانند بصورت مستقیم از ناحیه های غیرقابل اعتماد آدرس دهی شوند. هرچند توافق نظر درمیان کارشناسان امنیت نشان میدهد که این روش ویژگیهای امنیتی مناسب را فراهم نمیکند و درواقع میتواند از توسعه روشهای مناسب جلوگیری کند.

چنان رویه های پیاده سازی ای، کاربران اینترنت را به آنهایی که اتصال اینترنت «حقیقی» دارند و آنهایی که به استفاده از کاربردهایی که تنها اتصالات شبکه ای به سمت بیرون را استفاده میکنند تقسیم میکند.

==============================

منبع: http://en.wikipedia.org/wiki/End-to-end_connectivity

[eshpilen]

این مقاله رو که ترجمه کردم سوال و ابهامی برام پیش اومد و اون اینکه آیا اتصال اینترنتی که ISP ها به ما میدن (بدون داشتن IP ثابت)، میتونه از نوع اتصال حقیقی، یا دارای قابلیت End-to-end باشه یا نه.
اگر IP از نوع Share شده باشه (میان چند مشترک) بنظرم جواب منفی هست.
ولی نمیدونم آیا امکان داره همون IP غیرثابتی که یک ISP به یک مشتری میده در زمانی که مشتری از اون IP استفاده میکنه فقط اختصاصی همون مشتری باشه یا نه؟
البته شک دارم چنین IP غیر اشتراکی ولی متغییر رو طبق این مقاله بشه یک اتصال حقیقی اینترنت که دارای قابلیت End-to-end هست دونست. چون طرف دیگه قبل از دونستن IP ما قادر نیست با ما ارتباط برقرار کنه.

بهرحال این مشکل من بود که یه زمانی میخواستم دوتا برنامه رو روی دوتا PC با هم ارتباط مستقیم بدم، اما متوجه شدم بخاطر اینکه IP ها اشتراکی هست و ظاهرا ISP از NAT استفاده میکنه، امکان برقراری ارتباط مستقیم بین برنامه ها وجود نداره و مجبور شدم از هاست وب سایتی که داشتم بعنوان واسطهء ارتباط این دوتا برنامه استفاده کنم.
حتی اگر فقط یکی از این دوتا PC یک IP غیراشتراکی داشت میتونستم دوتا سیستم رو مستقیما به هم ارتباط بدم و اطلاعات اصلی دیگه از سرور وب عبور نکنه. حالا برای گرفتن IP اون PC توسط PC دیگه میتونستم فقط یک تماس ابتدایی با واسطهء سرور وب برقرار کنم و بعد از اینکه IP رایانهء مقصد دریافت شد، بقیهء ارتباطها بصورت مستقیم و بدون واسطه از طرف یکی از رایانه ها با رایانهء دارای IP غیراشتراکی انجام بشه.

کسی اگر تجربه و اطلاعاتی در این زمینه ها داره ممنون میشم بگه که استنباط من درست هست و چنین چیزی ممکنه یا نه.

[eshpilen]

اگر IP هر دو سیستم اشتراکی باشد, وصل کردنشان به یکدیگر شدنی نیست گرامی.

اشتراکی رو که میدونم. در متن که توضیح دادم.
ببین وقتی به ISP کانکت میشی، تاجایی که من میدونم سه تا حالت وجود داره:

۱) یک IP اختصاصی استاتیک داری که با اون به اینترنت وصل میشی
۲) یک IP که در هر بار اتصال تغییر میکنه و بین تعدادی مشترک به اشتراک گذاشته میشه بهت اختصاص داده میشه
۳) یک IP که در هر بار اتصال تغییر میکنه اما در هر اتصال تنها به یک مشتری اختصاص داده میشه

سوال من درمورد مورد ۳ هست که در این سناریو، آیا میشه سیستم دیگه ای در اینترنت با فرض دونستن اون IP که در اتصال به ما اختصاص داده شده، ارتباطی رو از طرف خودش با ما شروع بکنه یا نه؟

[FastCode]

در حالت اول که کاری نداره.
حالت سوم هم میشه.
برای حالت دوم یه مقاله هست به اسم how skype connects through the firewall که اگر بخونی دقیقاً میفهمی چه اتفاقی میافته.
توی این صفحه لینکهای اصلی اون مقاله هست ولی متاسفانه هردوشون حذف شدن.
http://www.cyberciti.biz/tips/howto-linux-iptables-bypass-firewall-restriction.html
حدود 10 صفحه بود با عکس.
این سرچ هم نتایج خوبی میاره:
http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=how+skype+connects+through+the+firewall#sclient= psy&hl=en&safe=off&q=how+skype+bypass+the+firewall&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=b8fdb3ae6eed2f03
اگر پیدا کردی لینکش رو بزار چون خودم میخوام دوباره بخونم.

[eshpilen]

اوه این روشهای مطرح شده واقعا جالب هستن. خبر نداشتم!
قبلا دربارهء این مشکل سوال کرده بودم جای دیگه اما بهم گفته بودن راهی نداره.
اونجا من پرسیده بودم پس چطور نرم افزارهای peer2peer روی سیستمهایی که اتصال اینترنت اشتراکی دارن کار میکنن، و دیگران گفتن کار نمیکنن! منم فکر کردم لابد در اینطور موارد یه سرور واسطه دارن یا اینکه ارتباط یک طرفه هست (مثلا درمورد BitTorrent (http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29)).

از میان منابعی که الان خوندم چنتایی رو که فکر میکنم مناسب تر هستن لیست میکنم:
http://alumnus.caltech.edu/~dank/peer-nat.html (http://alumnus.caltech.edu/%7Edank/peer-nat.html)

http://en.wikipedia.org/wiki/STUN
نکات مهم از همین منبع:


In many application scenarios it is common that both endpoints are located behind a NAT. This double-NAT problem is often not easily overcome even with STUN and sometimes an intermediate application proxy server is required.


http://en.wikipedia.org/wiki/TURN

http://en.wikipedia.org/wiki/NAT_traversal
نکات مهم از همین منبع:


Many techniques exist, but no single method works in every situation since NAT behavior is not standardized. Many techniques require assistance from a computer server at a publicly-routable IP address. Some methods use the server only when establishing the connection (such as STUN (http://en.wikipedia.org/wiki/STUN)), while others are based on relaying all data through it (such as TURN (http://en.wikipedia.org/wiki/TURN)), which adds bandwidth costs and increases latency, detrimental to real-time voice and video communications.


با این توضیحات میتونیم به این نتیجه برسیم که پیاده سازی چنین سیستمی پیچیده و حجیم هست. اگر بخوایم کامل باشه و هرجا و در هر شرایطی کار کنه که اصولا کار واقعا حرفه ای سخت و حجیمی هست. ضمنا تضمینی نیست که نیاز به سرور واسط نداشته باشیم. یعنی در خیلی موارد ارتباط مستقیم بدون واسطه ممکنه مقدور نباشه (ولی ارتباط ظاهرا میتونه از هر طرف آغاز بشه).

ولی بهرحال آزمایش کردن این روش به ساده ترین شکل ممکن برای کاربردهای موردی ارزشش رو داره. یادم باشه سرفرصت تستی بزنم در حد مختصر و خیلی ساده و موردی که آیا جواب میده یا نه.

[FastCode]

در درصد۹۵ واقع سرور واسط نیازی نیست.
اگر نیاز باشه باز هم در ۹۵ درصد مواقع مثل STUN ه نه TRUN.کار خیلی سختی هم نیست.زمانبر هست ولی پیچیده نیست.

[eshpilen]

متنهایی که منابع مختلف گفتن خلاف اینو میگه.
بخاطر اینکه NAT ها انواع مختلفی دارن و استانداردی هم بینشون وجود نداره، هیچکدوم از این روشها همه جا کار نمیکنن، و بنابراین اگر بخوایم یه سیستم کامل درست کنیم باید هوشمند باشه و ابتدا نوع و رفتار NAT رو مورد تحلیل قرار بده و تست کنه ببینه کدوم روش جواب میده و بعد اون روش رو بکار بگیره. خب این یخورده مسئله رو پیچیده میکنه نه؟
البته شاید مثلا یک نوع و ساختار خاصی از NAT خیلی متداول باشه یا مثلا در ایران بیشترش اونطوری هست که من نمیدونم. منم گفتم اگر بصورت ساده و موردی بخوایم پیاده کنیم ارزشش رو داره چون زیاده پیچیده و حجیم نیست. اما اگر بخوایم برنامه کامل و هوشمند باشه، کارش سختتر هست. اون لینک ها رو خونده باشی مثلا طرف خودش برای NAT های مختلف تست کرده و خیلی ها رو هم تست نکرده. یعنی تا تست عملی نکنی معلوم نیست چون یه روشی روی یکی کار میکنه روی یکی دیگه هم کار کنه.
منم منظورم این بود که اگر بخوایم کامل و هوشمند باشه خیلی مشکل تر بنظر میاد:

اگر بخوایم کامل باشه و هرجا و در هر شرایطی کار کنه...حالا فرقی نمیکنه 95% از یه نوع باشه یا نباشه. بهرحال همون 5% هم یه نقص هست و برنامهء ما بدون اون کامل نیست.
ضمنا از کجا اینقدر مطمئنی؟!

[FastCode]

NAT ها اینقدر که فکر میکنی پیچیده نیستند.
یه مقدار راجع به port triggering بخون.

[eshpilen]

نمیدونم شاید!
ولی نگفتی 95% رو از کجا آوردی؟
راستی قبلا خودت این کار رو کردی؟ یعنی نوشتن دو برنامه که مستقیما با هم ارتباط برقرار کنن و هردو پشت NAT باشن. مثلا ارتباط مستقیم دوتا سیستم که هر دو با دایالاپ معمولی به اینترنت وصل شدن (یعنی IP متغییر و اشتراکی دارن).

[eshpilen]

من میخوام این قضیه رو آزمایش کنم ولی نمیدونم چطوری، چون نیاز به دسترسی همزمان به دوتا سیستم دارم که هرکدوم جداگانه به اینترنت وصل باشن.
الان با سیستم خودم تست مقدماتی انجام دادم ولی با مشخص کردن IP دایالاپ خودم، ارتباط از طریق اینترنت عبور نمیکنه چون برنامه آدرس خود سیستم رو میده. تازه این روش مطمئنی هم نیست و باید با شرایط کاملا واقعی تست بشه، ولی برای شروع همین هم اگر شبیه سازی میشد بد نبود.

[Dr.Bronx]

من میخوام این قضیه رو آزمایش کنم ولی نمیدونم چطوری، چون نیاز به دسترسی همزمان به دوتا سیستم دارم که هرکدوم جداگانه به اینترنت وصل باشن.
الان با سیستم خودم تست مقدماتی انجام دادم ولی با مشخص کردن IP دایالاپ خودم، ارتباط از طریق اینترنت عبور نمیکنه چون برنامه آدرس خود سیستم رو میده. تازه این روش مطمئنی هم نیست و باید با شرایط کاملا واقعی تست بشه، ولی برای شروع همین هم اگر شبیه سازی میشد بد نبود.

از VMware استفاده کنید . ( نرم افزار های مشابه زیاده اما برای کاری که میخواید انجام بدید این رو توصیه می کنم )

موفق باشید ./

[eshpilen]

مطمئن نیستم درست باشه.
بهرحال من باید در شرایطی هرچه ساده تر و واقعی تر این روش رو تست کنم و این کار رو اگر بکنم صرفا برای آماده سازی اولیهء برنامه هست.
ضمنا سیستمم ضعیفه و نمیدونم با چه سرعتی میخواد یه سیستم عامل دیگه رو توی محیط مجازی اجرا کنه.

[Dr.Bronx]

شما با 1 گیگ رم به راحتی هر چه تمام تر می تونید یک سیستم عامل دیگرو ران کنید .

شرایطی واقعی تر از vmware به نظر من وجود نداره .

از این بالاتر که می تونید با remote desktop به اون سیستم مجازی که ساختید متصل بشید ؟

توضیحات بیشتری در مورد vmware خواستید در حد توان در خدمتم .

موفق باشید ./

[eshpilen]

شرایطی واقعی تر از vmware به نظر من وجود نداره .واقعیت واقعی تر از شبیه سازی هست!!
vmware اونقدرها هم واقعی نیست و محدودیت هایی داره.
در یه موردی فکر میکنم با یکی از این محدودیت ها برخورد کرده بودم قبلا. البته خودم نه ولی دیگران. کاربردش فکر میکنم در ارتباط با DirectShow بود که در vmware یه کتابخانه ای بود که درست کار نمیکرد اما وقتی طرف روی سیستم واقعی تستش کرد جواب داد. البته جزییات این ماجرا رو یادم نیست. مثل اینکه روی سیستم عامل یا سخت افزار ۶۴ بیتی بود. ضمنا کتابخانه رو از کدمنبع کامپایل کرده بودیم. خلاصه اینا مسائل رو پیچیده میکنه و پارامترهای خاصی رو بوجود میاره که ممکنه پیشبینی نشده باشن یا vmware نتونه اونا رو پاسخگو باشه.
بعدهم vmware سیستم عامل رو شبیه سازی میکنه، دیگه چیزهایی رو که خارج از تعریف و توان یک سیستم عامل هستن و مثلا نیاز به سخت افزار و امکانات خارجی جداگانه دارن که تامین نمیکنه! الان من فکر میکنم حتما نیاز به دوتا سیستم جدا باشه یا حداقل دو تا خط تلفن و دوتا مودم. چون در هر سیستم چه واقعی و چه شبیه سازی شده، بهرحال قواعد و ساختار یکسانی برقرار هست و در نهایت از سخت افزار و ارتباط اینترنتی مشترکی استفاده میکنن.

[eshpilen]

بنده این مسئله رو روی دوتا سیستم مجزا که هرکدوم از طریق دایالاپ به یک ISP متفاوت وصل میشدن تست کردم.

تست با UDP
جالبه که برخلاف انتظار، ارتباط UDP بین دو سیستم بدون مشکل و بدون نیاز به port punching انجام شد. این بنده رو به این نتیجه میرسونه که IP اختصاص داده شده باوجود متغییر بودن، با مشترکان دیگری به اشتراک گذاشته نشده. البته نمیدونم آیا این حالت رو همه یا چه درصدی از ISP ها دارن و آیا همیشه و تحت هر شرایطی اینطور هست یا خیر و ممکنه تاحد قابل توجهی تصادفی بوده باشه یا نه.

تست با TCP
ارتباط TCP از سیستم A به سیستم B انجام شد، اما از سیستم B به سیستم A صورت نگرفت. علتش نمیدونم چیه. اگر چیزی بنظر شما میرسه بگید. شاید ISP به علت خاصی این ارتباط رو Block میکنه. ولی اگر اینطوره به چه علتی و چرا ISP دیگه این کار رو نمیکنه؟

کدهایی که برای تست بکار رفتن رو میذارم تا اگر کسی خواست بررسی یا تست عملی بکنه:

کد برای UDP (به زبان پایتون):

server.py


import socket

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(('', 50007))
print('UDP Server is waiting for packets...')
while True:
data=s.recv(1000)
print("UDP data received: ", data.decode())
client.py


import socket

remoteAddr = ('localhost', 50007)

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

i=0
while True:
s.sendto("data{0}".format(i).encode(), remoteAddr)
print("data{0} sent".format(i))
i=i+1
input("hit Enter to repeat...")برای تست کافیه روی یکی از سیستمها server.py رو اجرا کنیم و روی سیستم دیگر client.py رو.

کد برای TCP (به زبان پایتون):

server.py


import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('', 50007))
s.listen(1)
print('TCP Server is waiting for connection...')
conn, addr = s.accept()
print('Connected by ', addr)

while True:
data = conn.recv(1024)
if not data: break
print("TCP data received: ", data.decode())

conn.close()client.py


import socket

remoteAddr = ('localhost', 50007)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(remoteAddr)

i=1

while True:
s.send("data{0}".format(i).encode())
print("data{0} sent".format(i))
i+=1
input("hit Enter to repeat...")

s.close()

کدها با پایتون 3.1 نوشته و روی ویندوز تست شدن.

[eshpilen]

خب اين داستان جالب بود و اميدواركننده تر از اوني كه فكر ميكردم. چون من فكر ميكردم كه وقتي با اينترنت دايالاپ وصل ميشيم اكثرا IP اشتراكي هست و پشت NAT قرار داريم و اتصال P2P چنين سيستمهايي هم دشوار و تضمين نشده هست. اما ظاهرا اينطور نيست!
فقط اگر بتونيم علت مشكل در اتصال TCP رو بفهميم و حلش كنيم خيلي خوب ميشه چون اين پروتكل بخشهاي مهمي از كار ارتباط رو انجام ميده و اگر نتونيم ازش استفاده كنيم مجبوريم از UDP استفاده كنيم و بقيهء كارها رو خودمون انجام بديم. منظورم از بقيهء كارها، ترتيب Packet ها و اطمينان از دريافت شدن اونهاست كه پروتكل TCP خودش انجام ميده، اما UDP خير. تا جاييكه ميدونم، در UDP شما يك Packet رو ميفرستيد ولي تضميني وجود نداره به مقصد برسه و ضمنا مرتب سازي Packet ها در مقصد بصورت خودكار انجام نميشه.

[FastCode]

خب اين داستان جالب بود و اميدواركننده تر از اوني كه فكر ميكردم. چون من فكر ميكردم كه وقتي با اينترنت دايالاپ وصل ميشيم اكثرا IP اشتراكي هست و پشت NAT قرار داريم و اتصال P2P چنين سيستمهايي هم دشوار و تضمين نشده هست. اما ظاهرا اينطور نيست!
فقط اگر بتونيم علت مشكل در اتصال TCP رو بفهميم و حلش كنيم خيلي خوب ميشه چون اين پروتكل بخشهاي مهمي از كار ارتباط رو انجام ميده و اگر نتونيم ازش استفاده كنيم مجبوريم از UDP استفاده كنيم و بقيهء كارها رو خودمون انجام بديم. منظورم از بقيهء كارها، ترتيب Packet ها و اطمينان از دريافت شدن اونهاست كه پروتكل TCP خودش انجام ميده، اما UDP خير. تا جاييكه ميدونم، در UDP شما يك Packet رو ميفرستيد ولي تضميني وجود نداره به مقصد برسه و ضمنا مرتب سازي Packet ها در مقصد بصورت خودكار انجام نميشه.
نمیدونم چه زبونی استفاده میکنی.
اگر C یا C++ استفاده میکنی میتونی از RUDP استفاده کنی.(اکثر implemention ها به زبان C++ هستند.)
اگر نه, پیشنهاد میکنم از TCP استفاده کنی.UDP خیلی اعصاب خورد کنه.
UDP در بعضی شبکه ها نیم درصد هم packet lose نداره ولی بعضی جاها از 10 درصد هم بیشتر میشه.این رو خودم دیدم.
در ضمن از پشت 2 تا NAT و 1 فایروال تا حالا کار کردم و خیلی راحت جواب گرفتم.(هیچ کانفیگ خاصی نیاز نیست.)

اون 95 درصد رو هم شهودی دیدم.من که اداره آمار نیستم.


بعدهم vmware سیستم عامل رو شبیه سازی میکنه، دیگه چیزهایی رو که خارج از تعریف و توان یک سیستم عامل هستن و مثلا نیاز به سخت افزار و امکانات خارجی جداگانه دارن که تامین نمیکنه! الان من فکر میکنم حتما نیاز به دوتا سیستم جدا باشه یا حداقل دو تا خط تلفن و دوتا مودم. چون در هر سیستم چه واقعی و چه شبیه سازی شده، بهرحال قواعد و ساختار یکسانی برقرار هست و در نهایت از سخت افزار و ارتباط اینترنتی مشترکی استفاده میکنن.
اگر نیاز به اینترنت نداری میتونی از دو تا روتر هم به جای دو تا مودم استفاده کنی.سرعتش بیشتره ولی فکر میکنم یک مقدار مسخرست

[eshpilen]

TCP ظاهرا مشکل داره. وگرنه کی بدش میاد؟
الان از دوتا ISP که من تست کردم یکیش با دریافت مستقیم ارتباط TCP از بیرون مشکل داره. معلوم نیست چرا و چه درصدی از ISP ها همینطور هستن و راه حل مناسبی داره یا نه.
راستی ریموت دسکتاپ ویندوز رو هم تست کردم دقیقا همین حالت بود. یعنی میتونستم به سیستمی که از طریق یکی از ISP ها به اینترنت وصل شده بود وصل بشم، اما درمورد ISP دیگه این کار ممکن نیست. ریموت دسکتاپ ویندوز هم از TCP استفاده میکنه.


UDP در بعضی شبکه ها نیم درصد هم packet lose نداره ولی بعضی جاها از 10 درصد هم بیشتر میشه.این رو خودم دیدم.
در ضمن از پشت 2 تا NAT و 1 فایروال تا حالا کار کردم و خیلی راحت جواب گرفتم.(هیچ کانفیگ خاصی نیاز نیست.)

اون 95 درصد رو هم شهودی دیدم.من که اداره آمار نیستم.
کارت مگه چیه و چند مورد مختلف از این کار داشتی؟
منکه نگفتم اداره آماری. همین گفتم که بگی اطلاعاتت بر چه مبنایی هست و تا چه حد مستدل و مستنده.
مثلا تست کردن فقط یکی دوتا ISP و NAT مسلما اطمینان خاصی به آدم نمیده که نتیجه گیری کلی و قاطعی بکنه.

[FastCode]

چه درصدی از ISP ها همینطور هستن
همه اینطوری هستند. :لبخند:


کارت مگه چیه و چند مورد مختلف از این کار داشتی؟
کارم مثل بقیه است. ولی تا حالا با ۱۵ ۱۶ تا شبکه کار کردم.

کارت مگه چیه و چند مورد مختلف از این کار داشتی؟
با ۵ ۶ تا آی اس پی کار کردم.
مخابرات بدون هیچگونه تردیدی از همه بهتره.
از همه بدتر(اصلاً برنامه دوست نداره کار بکنه) شاتله.با شاتل از همه بیشتر مشکل داشتم.

حدث میزنم مشکل شما از port triggering و port forwarding باشه.

[eshpilen]

حدث میزنم مشکل شما از port triggering و port forwarding باشه.
سیستمهایی که تست کردم عضو یک LAN نیستن. و هر دو مستقیما به اینترنت دایالاپ وصل شدن.

[eshpilen]

گفتم بيام حالتي رو هم كه حداقل يك سيستم پشت NAT هست تست كنم. بنابراين سيستمها رو با هم شبكه كردم و gateway سيستم B رو به IP داخلي سيستم A تنظيم كردم. اما نميدونم چرا وقتي با دايالاپ در سيستم A به اينترنت وصل ميشم، بازم سيستم B دسترسي اينترنت پيدا نميكنه. شما نميدونيد علتش چيه؟

راستي FastCode جان،اينترنت هوشمند شاتل رو هم تست كردم، جالب اينكه ارتباط TCP هم برقرار شد :لبخند:

[eshpilen]

اوه من اصلا حواسم به این نبود که اونایی که ADSL دارن بیشترشون پشت NAT هستن! چون مودم ADSL اکثرا بصورت PPPoE تنظیم شده و برای سیستمهایی که بهش وصل هستن بصورت NAT عمل میکنه؛ حتی اگر فقط یک سیستم بهش وصل باشه. درسته؟ من فقط با دایالاپ تست کردم.
پس حالا باز باید برم دنبال تست Port punching. مشکل اینه چطور اینو تست کنم. چون ADSL ندارم. یه نرم افزاری چیزی برای شبیه سازی NAT شاید باشه نه؟
راستی تاجایی که متوجه شدم، Port punching به اینصورت هست:
1- دو سیستمی که میخوان با هم ارتباط مستقیم داشته باشن به یک سرور واسط دارای IP مستقیم، بستهء UDP ارسال میکنن.
2- سیستم واسط آدرس و پورت بسته های دریافتی رو که میبینه به هر کدوم از سیستمهای دیگه اطلاع میده.
3- سیستمهای پشت NAT هرکدوم بسته های UDP رو بصورت همزمان به آدرس و پورت سیستم دیگه که توسط سرور واسط گزارش شده ارسال میکنن تا نهایتا Port ها باز بشه و ارتباط مستقیم برقرار گردد.
4- بقیش هم مخلفاتی مثل فرستادن بسته های منظم برای باز نگهداشتن پورت ها هست.
درسته FastCode جان؟

بعدشم باید یه فکری برای سرور واسط بکنم که چطور روش سرویس UDP راه بندازم. شاید با همون PHP بشه. نمیدونم سرور اجازه میده یا نه.

[FastCode]

درسته.
البته فرستادن بسته های منظم برای وقتیه که ارتباط از نوع udp باشه.
با php احتمالاً سخته.
البته من این زبون رو بلد نیستم ولی برای pc خودم که مجبور شدم باهاش کار کنم اولین مشکلی که بهش برخوردم انواع و اقسام timeout بود.که فکر میکنم توی این مورد اذیت کنه.
ولی با perl باید فوق العاده راحت باشه.
برای ارتباط با سرور رابط اگر از tcp استفاده کنید بهتره.چون اکثر فایروال ها(از جمله فایروال ویندوز) فکر میکنن udp جیززه.

[eshpilen]

آفرین راست میگی بهتره از TCP استفاده کنم. یعنی باید آزمایش کنم ببینم جواب میده یا نه. ظاهرا شماره پورت های اختصاص داده شده پشت سر هم هستن و یکی یکی زیاد میشن. بنابراین یا همون پورت کار میکنه یا پورت بعدی رو باید تست کنم. اتفاقا من گیر کرده بودم در مبحث UDP با PHP؛ یک کد روی لوکال نوشتم ولی خطای عجیب و لاینحلی میداد!

[eshpilen]

درسته.
البته فرستادن بسته های منظم برای وقتیه که ارتباط از نوع udp باشه.
با php احتمالاً سخته.
البته من این زبون رو بلد نیستم ولی برای pc خودم که مجبور شدم باهاش کار کنم اولین مشکلی که بهش برخوردم انواع و اقسام timeout بود.که فکر میکنم توی این مورد اذیت کنه.
ولی با perl باید فوق العاده راحت باشه.
برای ارتباط با سرور رابط اگر از tcp استفاده کنید بهتره.چون اکثر فایروال ها(از جمله فایروال ویندوز) فکر میکنن udp جیززه.

این دو روز اخیر یه تست با پایتون نوشتم که الگوریتمش حالت ترفند داشت (استفاده از ارتباط HTTP برای مشخص کردن پورت خارجی UDP)، ولی جالب بود. بعد تازه فهمیدم که ظاهرا فرضهایی که برای اونها الگوریتم رو طراحی کردم کاملا غلط بودن :لبخند:
تاجاییکه فهمیدم استفاده نکردن از ارتباط UDP با سرور واسط، کار رو خیلی پیچیده میکنه (و حتی شاید غیرممکن).
برای timeout من فکر میکنم میشه از این روش استفاده کرد که بسادگی، خود برنامهء کلاینت موقعی که میخواد با سرور واسط ارتباط UDP برقرار کنه اول بیاد و با یک درخواست HTTP، باعث اجرای یک اسکریپت PHP بشه که درواقع سرور UDP ما رو Run میکنه! بعدش هم که در همون timeout بنظرم زمان کافی برای انجام کارهای مربوط به تنظیم ارتباط P2P وجود خواهد داشت. به اینصورت سرور UDP هم لازم نیست بصورت مداوم روی سرور اجرا بشه درحالیکه ارتباط با اون فقط گهگاهی صورت میگیره (البته درمورد شرایط و تست ما).

فقط یه مشکل باقی میمونه! اونم اینکه فکر نمیکنم اصلا بشه روی Shared host ها، آدم خودش یه سرور Run بکنه! (فکر میکنم قبلا هم روی چندتا هاست تست کرده بودم و جواب نداده بود).
فکر کن روی یک هاست اشتراکی مگه میشه هرکس دلش خواست یک سرور از هر نوع دلخواه اجرا بکنه؟
بغیر از محدودیتهای فنی مربوط به هاستهای اشتراکی، اصلا فکر میکنم این با قوانین اونها هم جور درنمیاد. چون شما اون هاست و سرویس رو فقط برای سرویسهای تعریف شده ای که از طرف سرور ارائه میشن (وب و HTTP و ایمیل و ...) میگیری، نه اینکه خودت یک سرویس دیگه روی هاست اجرا کنی.

[eshpilen]

راستی الان به فکرم رسید که احتمالش زیاده سرویسهای رایگان که نقش سرور میانجی رو بازی کنن وجود داشته باشن!
من سرفرصت جستجو میکنم؛ اگر خودت هم سراغ داشتی خبرم کن.

[eshpilen]

الان چنتا لينك خوب پيدا و مطالعه كردم:
http://stackoverflow.com/questions/1223237/method-to-find-my-udp-sockets-real-port
http://stackoverflow.com/questions/1164656/p2p-network-games-apps-good-choice-for-a-battle-net-like-matching-server
http://www.voip-info.org/wiki/view/STUN
ظاهرا تعدادي سرورهاي رايگان STUN وجود دارن. فكر كنم بايد شروع كنم به كار كردن روی STUN!
راستي لينك دوم يخورده مطالب نامربوط زياد داره.
لينك سوم اطلاعات فني خيلي خوبي داره و چند سرور رايگان STUN رو هم معرفي كرده.
ضمنا از مطالعهء اين مطالب مشخص ميشه كه همونطور كه گفتم، از هاستهاي وب معمولي نميشه براي اين سرويس استفاده كرد.

[eshpilen]

بالاخره موفق شدم!

تاپیک های مرتبط:
پروژهء ارتباط P2P (http://barnamenevis.org/showthread.php?271364-%D9%BE%D8%B1%D9%88%DA%98%D9%87%D8%A1-%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7-P2P)
پروژهء STUN protocol client (http://barnamenevis.org/showthread.php?270992-%D9%BE%D8%B1%D9%88%DA%98%D9%87%D8%A1-STUN-protocol-client)

با تشکر از FastCode عزیز بابت تبادل نظر و راهنمایی هایی که در این ارتباط نسبت به بنده داشت.