sample client server app

  • Thread starter Thread starter jerryys
  • Start date Start date
J

jerryys

cannot find equivalent control for winsock in vb2005. can someone please
explain
why and additionally provide a small sample to get me going.

thanks

jerryys
 
cannot find equivalent control for winsock in vb2005. can someone please
explain
why and additionally provide a small sample to get me going.

thanks

jerryys

System.Net.TcpClient - I believe there are examples in the documentation.
 
System.Net.TcpClient - I believe there are examples in the documentation.

Oh... And System.Net.TcpListener for the server side.

You can also use the System.Net.Socket implementations as well. You
can find some good examples on msdn. I actually prefer to use the
Socket class - but, for simple stuff TcpClient/TcpListener are fine.
 
Where did you get the name client server app for a winsock application.

There are many misunderstanding about client server, but to call this from
1960 style applications client server is a little but to much marketing
language in my idea.

Cor
 
i'm not sure why marketing and the 1960's are being introduced, but a winsock
app in vb6 is intended to have a client side and a server side. please
explain the misunderstanding.

by the way, why in the world would a supposedly avanced language, vb2005 not
contain an easy to use compact winsock control as vb6. it seems vb2005 does
little when it comes to ease of use for communication pgms. i would have
expected a superior network control. and actually, in the 1960's cobol
communication pgms were referred to as network database apps.
 
by the way, why in the world would a supposedly avanced language, vb2005 not
contain an easy to use compact winsock control as vb6. it seems vb2005 does
little when it comes to ease of use for communication pgms. i would have
expected a superior network control. and actually, in the 1960's cobol
communication pgms were referred to as network database apps.

LOL... I'm sorry. But, to compare the winsock control to what's availabe in
..NET is kind of funny. The networking capablities introduced in System.Net
and System.Net.* are far superior to anything VB6 had to offer - short of
using the API and buying 3rd party controls.

The Winsock control in VB6 was only sufficient for very low load, simple
client/server applications.

If you talking about event handling - then, no problem. You simply use the
async methods of the TcpClient/TcpListener/Socket class. They will call back
to you when they have completed the task.
 
where in the world do you see me comparing both languages? what i point out
is the
regression to more basic levels of communication programming tools. quite
frankly
i dont know why vb2005 developers simply did not just force vb users to use
the
classes in C++. vb2005 is billed as an superior language to vb6 -- it is, so
i think they
could of moved into the future , not backwards. please read more carefully
next time before lol.

jerryys

:
 
where in the world do you see me comparing both languages?

LOL.. I never said you compared the languages, I said you compared the sorry
winsock control to the networking cababilities offered in .NET.

I wasn't trying to be rude - but having done lots of network programming in
both languages, I can tell you there is no "regression" that you speak of
below.
what i point out
is the
regression to more basic levels of communication programming tools.

Only someone unfamilar with the availabe classes would say that. If you need
simple, you have TcpClient/TcpListener (or UdpClient if you need to do udp).
These do both blocking and non-blocking io. All of the async options provide
for callback notification. Is the fact that they don't provide "Events"
what's making you say this?

If it will make you feel better - spend a couple of hours and write a winsock
control replacement. It's not that hard.
quite
frankly
i dont know why vb2005 developers simply did not just force vb users to use
the
classes in C++. vb2005 is billed as an superior language to vb6 -- it is, so
i think they
could of moved into the future , not backwards. please read more carefully
next time before lol.

LOL.. I'm not even sure I know what your saying here.
 
i dont believe i compare winsock in my statement. i do make an observation
about how microsoft decided to implement winsock facilities in .net. a true
comparison must conclude with which items compared are better, or the same. i
believe the more modern languages should not become more complex to use.
further in programming languages, the further down one regresses the more
power and flexibility one gains. this goes without saying. the problem is it
is more difficult to deal with lower level languages and many more statements
are required to perform a 1 line command in a higher level language. see code
for windows assembler language, which all languages ultimately get regressed
to in order to execute. surely you realize when vb6 was replaced by the .net
versions most vb6 programmers complained that a downward compatibility to vb6
was not possible. few said that .net was not more powerful, at least for
programming. it is intriguing to me that you refer to vb6 winsock control as
'sorry'. when vb6 was first introduced there was not really any difference
in microsoft's marketing statements for the product and it's power when
compared to statements made about .net versions. and i assume you thought
winsock was great then. in conclusion vb is a cute language for non
programmers to do basic home projects. programmers should stick to c++ or
lower level languages when developing for non main frame serious
applications.


jerryys
 
i dont believe i compare winsock in my statement. i do make an observation
about how microsoft decided to implement winsock facilities in .net. a true

In fact, you did - you talked about how there wasn't a high level facility
like the winsock control. But, ok.

assume you thought
winsock was great then.

You know that old statement about assuming? I was burned by the notorious
unreliablity of the winsock control and it's inabaility to handle serious
loads... I moved to using my own class wrappers around the winsock api after
the one and only time I used the winsock control.
in conclusion vb is a cute language for non
programmers to do basic home projects. programmers should stick to c++ or
lower level languages when developing for non main frame serious
applications.

What are you talking about? Are you some sort of language snob? I'm having a
hard time telling what your meaning is. My personal and professional
preference is not VB - but, I certainly don't think of it as a toy.
 
Tom, i appreciated your help with the links you provided at the start of this
sequence of replies and answers. Keep up the good work. Maybe you can help me
with a problem in the future.

jerryys
 
Back
Top