فرستادن فایل روی Lan به وسیله Socket نه Indy

[interrupt21]

اگر راهی برای فرستادن فایل و یا سورسی دارید ممنون میشم این مشکل منو حل کنید
TwinSocketStream یکی از راههاست که از thread و Send اون سر در نیووردم .
:متفکر:

[vcldeveloper]

عزیز جان، Indy هم از Socket برای ارسال/دریافت داده ها استفاده میکنه. من متوجه "به وسیله Socket نه Indy " نمیشم.

[interrupt21]

عزیز جان، Indy هم از Socket برای ارسال/دریافت داده ها استفاده میکنه. من متوجه "به وسیله Socket نه Indy " نمیشم.

در پلت اینترنت دلفی 6 دو کامپوننت به نامهای ServerSocket و ClientSocket هست که توی دلفی 7 باید نصب بشن تا ظاهر بشن . (منظورم TcpClient و TcpServer نیست) . منظور من از طریق ServerSocket و ClientSocket است .
باز هم میگم از طریق TwinSocketStream می شه . ولی راه درستش رو بلد نیستم
:متفکر: :گریه: :گریه:

[interrupt21]

کسی راهی بلد نیست

[Touska]

میشه بگید فرق idTcpServer با ServerSocket در کل چیه نه در جزء :(

که از اون نمی خواهید استفاده کنید.

[interrupt21]

میشه بگید فرق idTcpServer با ServerSocket در کل چیه نه در جزء :(

که از اون نمی خواهید استفاده کنید.

فرقشون تو اینه که idTcpServer از سیستم Blocking استفاده می کند و نمی توان عوضش کرد ولی ServerSocket از NonBlocking
دوما وقتی یه برنامه رو نوشتن تمام شد بر نمی گردن از اول تغییرات کلی بدن

[Touska]

Blocking is NOT Evil

بعد بعضی وقتها لازمه از تکنولوژی های جدید استفاده بشه حتی به قیمت تغییر کامل برنامه :

چون من هم از SocketServer استفاده کردم هم از IdTcpServer برای یک پروژه


Introduction to Indy Author: Chad Z. Hower
Homepage: http://www.atozedsoftware.com


Introductory Note

I originally wrote this article in the days of Indy 8.0. Most of the article still applies and is very useful for newer versions of Indy. If you like this article and would like to read many more in depth articles, please check out Indy in Depth.

Indy is Blocking

Indy uses blocking socket calls. Blocking calls are much like reading and writing to a file. When you read data, or write data, the function will not return until the operation is complete. The difference from working with files is that the call may take much longer as data may not be immediately ready for reading or writing (It can only operate as fast as the network or the modem can handle the data).

For example, to connect simply call the connect method and wait for it to return. If it succeeds, it will return when it does. If it fails, it will raise an exception.

Blocking is NOT Evil

Blocking sockets have been repeatedly attacked with out warrant. Contrary to popular belief, blocking sockets are not evil.

When Winsock was "ported" to Windows, a problem quickly arose. In Unix it was common to fork (kind of like multi threading, but with separate processes instead of threads). Unix clients and daemons would fork processes, which would run, and use blocking sockets. Windows 3.x could not fork and did not support multi threading. Using the blocking interface "locked" user interfaces and made programs unresponsive. So asynchronous extensions were added to WinSock to allow Windows 3.x with its shortcomings to use Winsock without "locking" the main and only thread of a program. This however required a different way of programming., and Microsoft and others vilified blocking vehemently so as to mask the shortcomings of Windows 3.x.

Then along came Win32 which could properly multi-thread. But at this point, everyone's mind had been changed (i.e. Developers believed blocking sockets were evil), and it is hard to "backtrack" once a statement has been made. So the continued vilification of blocking sockets continues.

In reality, blocking sockets are the ONLY way Unix does sockets. Blocking sockets also offer other advantages, and are much better for threading, security, and other aspects. Some extensions have been added for non-blocking sockets in Unix. However they work quite differently than in Windows. They also are not standard, and not in wide use. Blocking sockets under Unix still are used in almost every case, and will continue to be so.

Pros of Blocking

* Easy to program - Blocking is very easy to program. All user code can exist in one place, and in a sequential order.
* Easy to port to Unix - Since Unix uses blocking sockets, portable code can be written easily. Indy uses this fact to achieve its single source solution.
* Work well in threads - Since blocking sockets are sequential they are inherently encapsulated and therefore very easily used in threads.

Cons of Blocking

* User Interface "Freeze" with clients - Blocking socket calls do not return until they have accomplished their task. When such calls are made in the main thread of an application, the application cannot process the user interface messages. This causes the User Interface to "freeze" because the update, repaint and other messages cannot be processed until the blocking socket calls return control to the applications message processing loop.


و لینک کامل :

http://www.swissdelphicenter.ch/en/showarticle.php?id=4

[MZBCracker]

سلام.این سورس یه فایل رو با استفاده از tvlientsocket و tserversocket میفرسته.خودم هم سورسش رو بررسی کردم.تقریبا سادست.
http://www.planetsourcecode.com/vb/scripts/ShowZip.asp?lngWId=7&lngCodeId=783&strZipAccessCode=tp%2FS7833659
فکر نمیکنین بهتره بجای کل کل و عرض اندام به آدم بیچاره ای که سوال میپرسه جواب بدیم.چون با این کار بحث از موضوع مورد نظر خارج میشه.