communication over http
Ante Smolcic
I need to establish a communication between to comupters and transfer
some binary data as well. I was thinking of something like RMI in Java
or Remoting in .NET. I also need it to be over HTTP protocol so I can
get past firewall.
Please, any suggestions, what seems to be the easiest way?
--
I'm thinking... maybe dinner and a movie. I don't want to rush into
anything. I've been hurt, you know?
Maarten Wiltink
news:MPG.1c3e0ad4a...@news.iskon.hr...
> I need to establish a communication between to comupters and transfer
> some binary data as well. I was thinking of something like RMI in Java
> or Remoting in .NET. I also need it to be over HTTP protocol so I can
> get past firewall.
Wrong argument. Outbound traffic to port tcp/80 may be allowed, but that
is not the same as HTTP-over-TCP. Plus, once everybody starts hiding
their traffic in HTTP, firewalls will get more picky about what HTTP
traffic they allow.
SOAP springs to mind.
Keep in mind that HTTP is stateless challenge-response traffic, not a
connection or virtual circuit.
Groetjes,
Maarten Wiltink
Ante Smolcic
maa...@kittensandcats.net says...
Ok, thanks, but did you actually had any expirience with this stuff?
Let me put it this way:
One computer (client) has to call a function on the other computer
(server) and receive a response. This is pretty much like http, you make
a request with some data and you receive a repsonse with some data.
Anyway, I tried to create two applications (web-server and web-client)
with Indy components but failed, so I'm thinking there must be a RPC
mechanism over http somewhere in Delphi packages. Maybe CORBA od SOAP,
as you say. I know there are some components for that but I don't want
to spend two weeks fiddling with each one of them. I hope someone has a
straightforvard answer.
Thanks in advance
Maarten Wiltink
> In article <41d3f579$1$6217$e4fe...@news.xs4all.nl>,
> maa...@kittensandcats.net says...
>> "Ante Smolcic" <sp...@supersmola.net> wrote in message
>> news:MPG.1c3e0ad4a...@news.iskon.hr...
>>> I need to establish a communication between to comupters and transfer
>>> some binary data as well. I was thinking of something like RMI in
>>> Java or Remoting in .NET. I also need it to be over HTTP protocol
>>> so I can get past firewall.
>>
>> Wrong argument. Outbound traffic to port tcp/80 may be allowed, but
>> that is not the same as HTTP-over-TCP. Plus, once everybody starts
>> hiding their traffic in HTTP, firewalls will get more picky about
>> what HTTP traffic they allow.
>>
>> SOAP springs to mind.
>>
>> Keep in mind that HTTP is stateless challenge-response traffic, not
>> a connection or virtual circuit.
>
> Ok, thanks, but did you actually had any expirience with this stuff?
Not with SOAP, although I know the basics. With XML, HTTP, TCP,
firewalls, plenty.
> Let me put it this way:
>
> One computer (client) has to call a function on the other computer
> (server) and receive a response. This is pretty much like http, you make
> a request with some data and you receive a repsonse with some data.
It is. But there are limitations that normally you don't have.
Communication is asynchronous. Any number of clients can come knocking
all at once. You don't know which one is which. Each new request comes
into an empty context.
And that's the problems that can be solved. Now try to call a callback
function (event handler) in the client. Only the client can initiate
an exchange, the server has no way to signal the client if it doesn't
ask.
> Anyway, I tried to create two applications (web-server and web-client)
> with Indy components but failed, so I'm thinking there must be a RPC
> mechanism over http somewhere in Delphi packages. Maybe CORBA od SOAP,
> as you say. I know there are some components for that but I don't want
> to spend two weeks fiddling with each one of them. I hope someone has
> a straightforvard answer.
The simple answer is to forget about HTTP for the moment, you only think
you want it for bad reasons right now, and start by using plain TCP. That
_does_ give you a connection where both endpoints can choose to send at
any time and events will fire on the other side telling the process there
to react.
Write down your own simple, text-based protocol before ever making a
connection; you'll find it makes life much easier.
Groetjes,
Maarten Wiltink
John E. Doe
wrote:
>Anyway, I tried to create two applications (web-server and web-client)
>with Indy components but failed, so I'm thinking there must be a RPC
>mechanism over http somewhere in Delphi packages. Maybe CORBA od SOAP,
>as you say. I know there are some components for that but I don't want
>to spend two weeks fiddling with each one of them. I hope someone has a
>straightforvard answer.
>
>Thanks in advance
You're making things much too complicated on yourself.
If all you need is a client-server application, there are several
examples that come with Delphi (depending on what version you're
running).
Furthermore, there's no shortage of client-server freeware/shareware
that you can find on countless web sites.
VBDis
<nobody...@dontneedspam.com> schreibt:
>If all you need is a client-server application, there are several
>examples that come with Delphi (depending on what version you're
>running).
I still miss an example for a connection that transfers commands and responses
until the connection is terminated. Something like the chat demo, but not
exactly that.
My intended application is a BGI server, that shows the BGI output of a client
application in a dedicated window. For every new client a new window must be
created, and only the output of that client shall become visible in that
window. You can forget about BGI and assume e.g. a remote log window, but some
commands require that the server sends back requested information to the client
as well.
I could make that work, somehow, but the code and procedures are not very
pleasant. Too many windows on the screen, how to start the server if not
already running, which port numbers to use etc. :-(
Perhaps a service instead of an application would be better, but how that?
DoDi
Maarten Wiltink
news:20050106173622...@mb-m22.aol.com...
[...]
> I still miss an example for a connection that transfers commands and
> responses until the connection is terminated. Something like the chat
> demo, but not exactly that.
>
> My intended application is a BGI server, that shows the BGI output of
> a client application in a dedicated window. For every new client a new
> window must be created, and only the output of that client shall become
> visible in that window. You can forget about BGI and assume e.g. a
> remote log window, but some commands require that the server sends back
> requested information to the client as well.
>
> I could make that work, somehow, but the code and procedures are not
> very pleasant. Too many windows on the screen, how to start the server
> if not already running, which port numbers to use etc. :-(
>
> Perhaps a service instead of an application would be better, but how
> that?
You are describing X Windows.
Groetjes,
Maarten Wiltink
VBDis
<maa...@kittensandcats.net> schreibt:
>You are describing X Windows.
As used on Linux, or some existing Windows library/service?
DoDi
Maarten Wiltink
Yes.
It's OS-independent and there are implementations for many OSes,
including Windows via Cygwin.
An X client application links against xlib as a Windows application
links against WinAPI, but Posix and X separate the OS from the
windowing interface. There are (many) widget sets for X which
abstract the base platform in the same way the VCL does for WinAPI.
BTW, I have no experience developing for X.
X servers, the side _displaying_ the window, are available
natively for Windows, too. I've been evaluating NetSarang XManager
for quite some time now and I must say it works flawlessly.
Groetjes,
Maarten Wiltink
VBDis
<maa...@kittensandcats.net> schreibt:
>It's OS-independent and there are implementations for many OSes,
>including Windows via Cygwin.
I'm not sure that we mean the same. My requirements are Delphi code (TP
compatible in the best case) and that the output window survives a termination
or crash of the client.
>An X client application links against xlib as a Windows application
>links against WinAPI, but Posix and X separate the OS from the
>windowing interface. There are (many) widget sets for X which
>abstract the base platform in the same way the VCL does for WinAPI.
My problem is not a separation between the graphics and the OS, instead it's
the communication between client and server. The implementation of the BGI
output window is no problem, I did it with direct API calls instead of forms.
The real problem is the framework, required to transmit the commands and
responses between client and server. Here TCP/IP is a requirement, otherwise I
had used SendMessage for simplicity.
DoDi
Maarten Wiltink
I'm not saying you must now use X because you want some features it
offers. Just pointing out that people have already solved your problems;
it's fine with me if you want to duplicate the typing and/or the thinking
but it's a way to start. A source of ideas and book titles.
It seems likely that Cygwin produces DLLs with header files that a
Delphi program could be dynamically linked against. Turbo Pascal would
require import libraries somehow, I think.
The X server, which hosts the individual output windows, would survive
a crash of any remote client. Its window would hang and probably die
after some timeout.
I mentioned the separation between graphics and OS only because "uses
Windows" provides in one package things that would be separated into libc
and xlib on Unix.
What you seem to need is a set of proxies that let you supply input and
view output with some degree of network transparency. X Windows is such
a framework, and making your server an X client means you can reuse the
existing work in it. An X client tells xlib where its display is and
starts drawing on canvases or creating widgets.
But you might just as well write a BGI server proxy and a BGI client
proxy that give you network transparency.
Groetjes,
Maarten Wiltink
Marco van de Voort
>> <maa...@kittensandcats.net> schreibt:
>> My problem is not a separation between the graphics and the OS, instead
>> it's the communication between client and server. The implementation of
>> the BGI output window is no problem, I did it with direct API calls
>> instead of forms. The real problem is the framework, required to transmit
>> the commands and responses between client and server. Here TCP/IP is a
>> requirement, otherwise I had used SendMessage for simplicity.
>
> I'm not saying you must now use X because you want some features it
> offers. Just pointing out that people have already solved your problems;
> it's fine with me if you want to duplicate the typing and/or the thinking
> but it's a way to start. A source of ideas and book titles.
>
> It seems likely that Cygwin produces DLLs with header files that a
> Delphi program could be dynamically linked against.
I assume that this would be possible. If you want, I can test this. If there
is a problem, it is cygwin dll init.
Note that C++ linking (e.g. QT) will most likely fail.
> Turbo Pascal would require import libraries somehow, I think.
TP/Dos can't interface to windows subsystems (except a few int 2f calls),
and cygwin as win32 app counts as such, TP/Windows has only support for
16-bit dll, and needs elaborate thunking systems for 32-bit code access
iirc.
> I mentioned the separation between graphics and OS only because "uses
> Windows" provides in one package things that would be separated into libc
> and xlib on Unix.
Indeed, but much more than just those two, be careful there. Linux glibc is
not standard, and includes gettext that is separate on other platforms. So
on most platforms you will need
- libdl for dynloading of libs (loadlibrary and friends) (but OTOH FreeBSD
has libdl in libc)
- gettext for internationalisation
- pthreads for threading.
- ncurses for text console abstraction
- libX11, libXt
etc etc.
To give you an idea, here is what lazarus uses (a gtk app) on FreeBSD:
-bash-2.05b$ ldd lazarus
lazarus:
1 libgdk12.so.2 => /usr/X11R6/lib/libgdk12.so.2 (0x28498000)
2 libgtk12.so.2 => /usr/X11R6/lib/libgtk12.so.2 (0x284cc000)
3 libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x285f4000)
4 libgdk_pixbuf.so.2 => /usr/X11R6/lib/libgdk_pixbuf.so.2 (0x286b2000)
5 libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x286c6000)
6 libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x286ce000)
7 libm.so.2 => /usr/lib/libm.so.2 (0x286dc000)
8 libglib12.so.3 => /usr/local/lib/libglib12.so.3 (0x286f7000)
9 libc.so.4 => /usr/lib/libc.so.4 (0x28719000)
10 libgmodule12.so.3 => /usr/local/lib/libgmodule12.so.3 (0x287b2000)
11 libintl.so.6 => /usr/local/lib/libintl.so.6 (0x287b5000)
12 libXThrStub.so.6 => /usr/X11R6/lib/libXThrStub.so.6 (0x287be000)
13 libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x287c0000)
-bash-2.05b$
- 1,2,8,10 are part of gtk,
- 3,5,6,12 is X (x11= client, Xi=X intrinsics, Xext=X extensions, XThrStub
is thread safety (TLS) stuff iirc)
- 4 is an canvaslike extension to gtk iirc
- 11,13 are iirc part of the internationalisation package gettext
- 9 is libc
- 7, libmath is a collection of floating point helpers.
- (invisible statically linked) is libgcc, the gcc base stub
(64-bit language helpers mainly)
VBDis
<maa...@kittensandcats.net> schreibt:
>But you might just as well write a BGI server proxy and a BGI client
>proxy that give you network transparency.
This is what I did already, as my first step into networking. Using X Windows
will add another step into X, what IMO is overkill for the intended purpose. It
also wouldn't cure my ignorance with regards to TCP/IP programming ;-)
DoDi