Intercommunication control?

[M O J O]

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

[Tom Shelton]

Re: Intercommunicat ion control?

On Oct 31, 4:33 am, M O J O <m...@nospam.no spamwrote:

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 pretty
good 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

[Spam Catcher]

Re: Intercommunicat ion control?

Tom Shelton <tom_shelton@co mcast.netwrote in
news:1193840415 .520879.158000@ 50g2000hsm.goog legroups.com:

On Oct 31, 4:33 am, M O J O <m...@nospam.no spamwrote:

>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.

[M O J O]

Re: Intercommunicat ion control?

Hi Tom,

Thank you for answering me.

I will look at all your suggestions.

Thanks agan!

:o)

M O J O

Tom Shelton skrev:

On Oct 31, 4:33 am, M O J O <m...@nospam.no spamwrote:

>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 pretty
good 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
>

[M O J O]

Re: Intercommunicat ion control?

Hiya,

Well I dunno about remoting either ... is there a good place for
begginers to learn?

Thanks!!

M O J O

Spam Catcher skrev:

Tom Shelton <tom_shelton@co mcast.netwrote in
news:1193840415 .520879.158000@ 50g2000hsm.goog legroups.com:
>

>On Oct 31, 4:33 am, M O J O <m...@nospam.no spamwrote:

>>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.
>

[Tom Shelton]

Re: Intercommunicat ion control?

On Oct 31, 12:11 pm, Spam Catcher <spamhoney...@r ogers.comwrote:

Tom Shelton <tom_shel...@co mcast.netwrote innews:11938404 15.520879.15800 0@50g2000hsm.go oglegroups.com:
>
>
>
>
>

On Oct 31, 4:33 am, M O J O <m...@nospam.no spamwrote:

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 -

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....

That said, I agree that often wcf/remoting is probably the best
answer.

--
Tom Shelton

[Andrew Faust]

Re: Intercommunicat ion control?

You can try indy:

>
http://www.indyproject.org/index.en.aspx

I haven't used Indy for several years and it was Delphi only at the time.
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@co mcast.netwrote in message
news:1193840415 .520879.158000@ 50g2000hsm.goog legroups.com...

On Oct 31, 4:33 am, M O J O <m...@nospam.no spamwrote:

>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 pretty
good 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
>

[Spam Catcher]

Re: Intercommunicat ion control?

Tom Shelton <tom_shelton@co mcast.netwrote in
news:1193873411 .358972.109790@ i38g2000prf.goo glegroups.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 ;-)

[Jeffrey Tan[MSFT]]

Re: Intercommunicat ion control?

Hi Mojo,

You may take a start from the link below:
".NET Framework Remoting Overview"
http://msdn2.microsoft.com/en-us/library/kwdt6w2k.aspx

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[Tom Shelton]

Re: Intercommunicat ion control?

On Oct 31, 8:04 pm, Spam Catcher <spamhoney...@r ogers.comwrote:

Tom Shelton <tom_shel...@co mcast.netwrote innews:11938734 11.358972.10979 0@i38g2000prf.g ooglegroups.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 ;-)

I am very aware of what .NET sockets are and what they aren't. I've
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