2Modem phone-line communication

[Guest]

I'm not exactly sure where to put this, so I'm sorry if this is in the wrong
place...

(I'm using Visual Studio 2003, Framework 1.1, Windows 2000 Pro, and DirectX
9.0 December 2004 Update)

Here's my problem:
I'm trying to write a pair of programs (one running a physical simulation,
the other a dummy look-alike) that can communicate to each other from two
different computers (both running Windows 2000 Pro). The internet connection
between them is not reliable, so I'm trying to link them modem to modem
across a phone line. I want to be able to have one machine call into the
other, estblish a connection, and then send simple messages back and forth
(Mostly user commands and various screen updates).

I'm VERY new at this sort of thing, so I don't have any idea where to start
(even if I have to wait for VS 2005, framework 2.0, or Vista, I would still
like something...)

Thanks for your time.
-22

 

[DickGrier]

Hi,

Well, I have lots of information in my book (below) about modem
communications. What you want to do requires that you do two things (one
easy, and one more difficult).

First dialing and answering a modem. I have examples in my book, and you
can download DesktopSerialIO from my homepage. It is a .NET dll for serial
communications that makes the interface as simple as possible (I hope).

Second, is the creation of a command and response protocol that will send
the information between your PCs necessary to do the "screen update." I
presume that you are not trying to send entire images, etc., but are simply
sending a series of messages that may be interpreted by the receiving progam
so that it can do whatever screen update is needed?

Such protocols are ad hoc. That is, you decide what a command means (and if
a response is required), and write code that implements the sending of the
command and the interpretation on receipt. A protocol can be as simple or
as complex as you need it to be. There aren't any rules. I have example
code in my book for a command/response protocol that could be used -- but it
may be more complex than you really need. What I'm saying is that there
isn't any single "right way" to do this. There are lots of possibilities
and what actually you should implement depends on things that are not
revealed in your post -- and there is lots of "wiggle-room" after that.

Feel free to ask specific questions here, and I'll try to help.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition, ISBN 1-890422-28-2, Mabry Publishing (391 pages, includes CD-ROM).
July 2004.
See www.hardandsoftware.net for details and contact information.

 

[Guest]

Thankyou, this is exactly the kind of answer I was looking for.

I presume that you are not trying to send entire images, etc., but are simply
sending a series of messages that may be interpreted by the receiving progam
so that it can do whatever screen update is needed?
...

There are lots of possibilities
and what actually you should implement depends on things that are not
revealed in your post -- and there is lots of "wiggle-room" after that.

Here's the situation:
I have a program originally written in DOS that I'm converting to Windows.
In order to ensure that the users don't have to relearn the system, I'm
trying to make it look like DOS. DOS screens aren't very complicated and only
require a series of 80x24 ascii characters to represent the entire screen,
which is 640x400 pixels. Since the connection has to be made across two 56k
modems (same brand), it makes most Remote Control programs almost unusable.
As a programmer, I prefer more permanent solutions, so I'm looking for a way
to communicate with the least amount of overhead.

As you suspected, I plan on sending messages between the two computers that
are interpreted on each side of the connection. The simulation program (the
real one) will only be sending updates and receiving user commands (or
key-strokes, depending on how well this kind of connection performs). The
screen updates itself completely every half-second, so large bandwidth isn't
necessary. The screen updates will most likely consist of either a String or
Byte array, depending on efficiency. As for the user commands, they will be
either simple Integers or KeyCodes. Nothing very complicated at all.

I hope this is a bit more specific.
-22

 

[DickGrier]

Hi,
As you suspected, I plan on sending messages between the two computers that
are interpreted on each side of the connection. The simulation program (the
real one) will only be sending updates and receiving user commands (or
key-strokes, depending on how well this kind of connection performs). The
screen updates itself completely every half-second, so large bandwidth isn't
necessary. The screen updates will most likely consist of either a String or
Byte array, depending on efficiency. As for the user commands, they will be
either simple Integers or KeyCodes. Nothing very complicated at all.
<<

By your description, you need 1920 bytes to represent a screen. With
protocol overhead, slightly less than 2000 bytes. Since a conventional
dialup modem can pass data end-to-end at a maximum speed of 33K bps (higher
speeds are restricted to connections to the internet, not between two PCs --
the speed on the telephone line is this maximum, even though the serial port
speed is much higher), your basis screen update will consume ALL of the
available bandwidth if you attempt two per second. I suspect, at the end of
the day, that you may not see much more than two every three seconds at
best, and perhaps only one per second.

Still, I see nothing very difficult about the situation, if you can live
with the bandwidth limitation. The keystrokes and other commands will not
have any significant impact on screen updates.

Building a protocol to handle this doesn't sound difficult. If I were to do
it, it might take a couple of days, though. So, don't underestimate your
time.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition, ISBN 1-890422-28-2, Mabry Publishing (391 pages, includes CD-ROM).
July 2004.
See www.hardandsoftware.net for details and contact information.

 

[Guest]

Still, I see nothing very difficult about the situation, if you can live
with the bandwidth limitation. The keystrokes and other commands will not
have any significant impact on screen updates.

Building a protocol to handle this doesn't sound difficult. If I were to do
it, it might take a couple of days, though. So, don't underestimate your
time.

Most screens won't require a WHOLE screen update, and for the most part,
only less than half every half-second. With some assumptions made on the
user's end (like not transfering standard headers), I can probubly cut down
screen display quite a bit. I can find a way to make due with the given
bandwith.

However, that leaves the Protocol. Sadly, I've never built my own protocol,
and for the most part, I'm not really sure how to go about creating one (in
fact, I'm not sure what a protocol is, beyond a handshake used for data
transfer). Any information on the steps required (or a good source, like your
book), would be greatly appreciated.

-22

 

[DickGrier]

Hi,

I don't have any examples, except the one in my book. Usually these are
created on a case-by-case basis, with the details left to the designer.
However, it is easiest to think of a protocol as a series of characters
(packet) that has a pre-defined data format. For example:

StartByte (Chr$(1) for example)
CommandByte (a character that specifies the data to follow)
DataLengthBytes (two or more characters that specify the length of ACTUAL
DATA -- if any -- that follow)
Data (the series of characters with the format specified by the CommandByte)
EndByte (Chr$(4) for example)
Checksum (optional, but "nice")

So, you build up a packet that contains the data to follow the recipe that
you've choosen. Then, you send it. On the receiving side, you simply look
for a stream of characters (appending them as they arrive to a buffer that
you can use to parse out the content), first for a StartByte, then and
EndByte. All of the characters between those two characters are decoded so
that they can be interpreted. You use the LengthByte and optional Checksum
to determing if everything "fits" a proper packet format.

You can add an acknowlegement packet to let the sending side know that the
packet has been received or send a negative ack if corrupted (also optional,
but a typical design includes ACK/NAK).

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition, ISBN 1-890422-28-2, Mabry Publishing (391 pages, includes CD-ROM).
July 2004.
See www.hardandsoftware.net for details and contact information.