 | |
Intercommunication control?
Dotnet Framework (Remoting) microsoft.public.dotnet.framework.remoting
 |
| | Thread Tools | Search this Thread | Display Modes |
#1
 
| |||
| |||
|
Intercommunication control? -
10-31-2007
, 05:33 AM
#2
| |||
| |||
|
|
Hi, I have absolutely no clue how to do TCP Client/Server stuff. I would like to drop a "server control" on my server form, a "client control" on my client form, set some parameters like port and then just enable it. The controls will take care of the rest (like if the server restarts, the client will reconnect automatically and so on). Is there a component "out there" I can drop on my form and don't worry about the communication?? I'm willing to pay for it - it just have to work. Thanks! M O J O |
http://www.indyproject.org/index.en.aspx
Haven't used it myself, so I'm not sure how easy/difficult it is to
use - but seems to be a popular choice. There's also Catalyst's
socketwrench stuff:
http://www.catalyst.com/products/socketwrench/
I've worked with this in the past, seems to work pretty well. I'm
pretty sure nsoftware has some socket communications components as
well.
Still, my preference is to just use the classes in System.Net. They
really aren't that hard to use, and they are free
Here is a prettygood starting point:
http://msdn2.microsoft.com/en-us/library/b6xa24z5.aspx
Using them syncronously, is the easiest - but, asyncronously is more
scalable. So, depending on how many clients you expect, you can
decide wich way to go.
--
Tom Shelton
#3
| |||
| |||
|
|
On Oct 31, 4:33 am, M O J O <m... (AT) nospam (DOT) nospam> wrote: Hi, I have absolutely no clue how to do TCP Client/Server stuff. I would like to drop a "server control" on my server form, a "client control" on my client form, set some parameters like port and then just enable it. The controls will take care of the rest (like if the server restarts, the client will reconnect automatically and so on). Is there a component "out there" I can drop on my form and don't worry about the communication?? I'm willing to pay for it - it just have to work. Thanks! M O J O You can try indy: http://www.indyproject.org/index.en.aspx |
Don't use sockets unless you absolutely have to - it's too much work for
a beginner.
Look at using WCF or remoting instead.
#4
| |||
| |||
|
)|
On Oct 31, 4:33 am, M O J O <m... (AT) nospam (DOT) nospam> wrote: Hi, I have absolutely no clue how to do TCP Client/Server stuff. I would like to drop a "server control" on my server form, a "client control" on my client form, set some parameters like port and then just enable it. The controls will take care of the rest (like if the server restarts, the client will reconnect automatically and so on). Is there a component "out there" I can drop on my form and don't worry about the communication?? I'm willing to pay for it - it just have to work. Thanks! M O J O You can try indy: http://www.indyproject.org/index.en.aspx Haven't used it myself, so I'm not sure how easy/difficult it is to use - but seems to be a popular choice. There's also Catalyst's socketwrench stuff: http://www.catalyst.com/products/socketwrench/ I've worked with this in the past, seems to work pretty well. I'm pretty sure nsoftware has some socket communications components as well. Still, my preference is to just use the classes in System.Net. They really aren't that hard to use, and they are free Here is a prettygood starting point: http://msdn2.microsoft.com/en-us/library/b6xa24z5.aspx Using them syncronously, is the easiest - but, asyncronously is more scalable. So, depending on how many clients you expect, you can decide wich way to go. -- Tom Shelton |
#5
| |||
| |||
|
|
Tom Shelton <tom_shelton (AT) comcast (DOT) net> wrote in news:1193840415.520879.158000 (AT) 50g2000hsm (DOT) googlegroups.com: On Oct 31, 4:33 am, M O J O <m... (AT) nospam (DOT) nospam> wrote: Hi, I have absolutely no clue how to do TCP Client/Server stuff. I would like to drop a "server control" on my server form, a "client control" on my client form, set some parameters like port and then just enable it. The controls will take care of the rest (like if the server restarts, the client will reconnect automatically and so on). Is there a component "out there" I can drop on my form and don't worry about the communication?? I'm willing to pay for it - it just have to work. Thanks! M O J O You can try indy: http://www.indyproject.org/index.en.aspx Don't use sockets unless you absolutely have to - it's too much work for a beginner. Look at using WCF or remoting instead. |
#6
| |||
| |||
|
|
Tom Shelton <tom_shel... (AT) comcast (DOT) net> wrote innews:1193840415.520879.158000 (AT) 50g2000hsm (DOT) googlegroups.com: On Oct 31, 4:33 am, M O J O <m... (AT) nospam (DOT) nospam> wrote: Hi, I have absolutely no clue how to do TCP Client/Server stuff. I would like to drop a "server control" on my server form, a "client control" on my client form, set some parameters like port and then just enable it. The controls will take care of the rest (like if the server restarts, the client will reconnect automatically and so on). Is there a component "out there" I can drop on my form and don't worry about the communication?? I'm willing to pay for it - it just have to work. Thanks! M O J O You can try indy: http://www.indyproject.org/index.en.aspx Don't use sockets unless you absolutely have to - it's too much work for a beginner. Look at using WCF or remoting instead.- Hide quoted text - - Show quoted text - |
standpoint. I would say that simple socket communication is far
easier both from a programming and setup perspective....
That said, I agree that often wcf/remoting is probably the best
answer.
--
Tom Shelton
#7
| |||
| |||
|
|
You can try indy: http://www.indyproject.org/index.en.aspx |
However, I loved them and would highly recommend them. Plus they're open
source with a very permissive license.
--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com
"Tom Shelton" <tom_shelton (AT) comcast (DOT) net> wrote
Quote:
|
On Oct 31, 4:33 am, M O J O <m... (AT) nospam (DOT) nospam> wrote: Hi, I have absolutely no clue how to do TCP Client/Server stuff. I would like to drop a "server control" on my server form, a "client control" on my client form, set some parameters like port and then just enable it. The controls will take care of the rest (like if the server restarts, the client will reconnect automatically and so on). Is there a component "out there" I can drop on my form and don't worry about the communication?? I'm willing to pay for it - it just have to work. Thanks! M O J O You can try indy: http://www.indyproject.org/index.en.aspx Haven't used it myself, so I'm not sure how easy/difficult it is to use - but seems to be a popular choice. There's also Catalyst's socketwrench stuff: http://www.catalyst.com/products/socketwrench/ I've worked with this in the past, seems to work pretty well. I'm pretty sure nsoftware has some socket communications components as well. Still, my preference is to just use the classes in System.Net. They really aren't that hard to use, and they are free Here is a prettygood starting point: http://msdn2.microsoft.com/en-us/library/b6xa24z5.aspx Using them syncronously, is the easiest - but, asyncronously is more scalable. So, depending on how many clients you expect, you can decide wich way to go. -- Tom Shelton |
#8
| |||
| |||
|
|
I wouldn't say that it is necessarily easier from a beginers standpoint. I would say that simple socket communication is far easier both from a programming and setup perspective.... |
account, such as buffer overflows, errors during data transfer, sending
large amount of data, etc etc. There's just too many small details for a
beginner to worry about.
Quote:
|
That said, I agree that often wcf/remoting is probably the best answer. |
clients... I swore to myself I'll never do that again ;-)
#9
| |||
| |||
|
|
Tom Shelton <tom_shel... (AT) comcast (DOT) net> wrote innews:1193873411.358972.109790 (AT) i38g2000prf (DOT) googlegroups.com: I wouldn't say that it is necessarily easier from a beginers standpoint. I would say that simple socket communication is far easier both from a programming and setup perspective.... There's a lot of stuff the standard .NET socket libraries don't take into account, such as buffer overflows, errors during data transfer, sending large amount of data, etc etc. There's just too many small details for a beginner to worry about. That said, I agree that often wcf/remoting is probably the best answer. I wrote a socket server which handles >150 simultaneous call center clients... I swore to myself I'll never do that again ;-) |
done lots of work with them - everything from writing my own
webserver, email clients, and news readers. Not to mention, a
predictive dialer system that integrated with a legacy system via a
tcp/ip server that handled probably double 150+ connections and a
service to pull data off of an sql database for clients running on a
Unix environment.... Yes, there are details you have to deal with when
doing more complex stuff - but, it sure sounds to me that the OP isn't
dealing with complex stuff.
Still - I agree that in his case, wcf/remoting is probably a better
answer. But, I don't necessarily agree that remoting is simpler, it
has it's details to work through as well. Like the differences
between client and server activated objects? What is a singleton?
What protocol should be used for serialization? etc, etc. Anway, I
don't want to get into an argument. The OP asked about tcp/ip
controls - so I answered that. You added the thought to use
remoting. I think the OP has enought information now to make an
informed decision
--
Tom Shelton
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.