Intercommunication control?

  • Thread starter Thread starter M O J O
  • Start date Start date
M

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
 
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
Click to expand...

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.
 
Hi Tom,

Thank you for answering me.

I will look at all your suggestions.

Thanks agan!

:o)

M O J O

Tom Shelton skrev:
 
Hiya,

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

Thanks!!

M O J O

Spam Catcher skrev:
 
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 -
Click to expand...

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.
 
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....
Click to expand...

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.
Click to expand...

I wrote a socket server which handles >150 simultaneous call center
clients... I swore to myself I'll never do that again ;-)
 
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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
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.


I wrote a socket server which handles >150 simultaneous call center
clients... I swore to myself I'll never do that again ;-)
Click to expand...

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 :)
 
Back
Top