>I have a problem that I haven't been able to solve, and I thought--again, 
>since I've posted a brief version of a part of this issue before--that
>perhaps someone on the list might be able to help.  And sorry I had to make
>it so long-winded....
>
>Problem: I have a dual server configuration where a dedicated "slave" server
>(500 Mhz G4 Mac) is giving database services by being directly connected to
>a database-application/internet server (NT dual 700 Mhz Dell) listening for
>WAN/http calls for data.  MC is a custom browser asking for db record data.
>While in a true WAN  environment, approximately 5-10% of my MC-generated
>"post" calls never generate a return from the http server, even though the
>database records being called for are clearly found and delivered to the NT
>(as apparent in the db application's "found records" status when looking at
>the NT server directly). Netscape/IE _never_  fail to generate returns when
>we query the db through the web, which throws some suspicion on MC.
>
>Details are:
>
>I am using post commands similar to one provided below to communicate
>through lasso (CGI application from BlueWorld) with FileMaker Pro
>application/database  located on the web/db servers. FileMaker Pro database
>is used as a back end for  my MetaCard stacks on the client machines.
>
>I moved this configuration to a relatively quite LAN with very good
>bandwidth for benchwork evaluations and the failures still persist, only at
>about a .5-1% rate instead of the 5-10% rate.  I am still evaluating setups
>and all that jazz on the NT to see if the NT is the problem, but still have
>to wonder whether MC is in any way at fault or can be used to generate a
>"work-around" solution.  For example, if MC just didn't "hang" when the
>response doesn't come back in, I could check for returned results, if
>finding empty-- re-send the query and go on.
>
>OK.
>
>I did a little experimenting and it appears that instead of using the "post"
>command  I may use a "put"  command as well.
>
>This means that instead of
>
>  post
>"-database=Students.fp3&-layout=FirstStep&-response=Field:'gbRespOne'&-recor
>dI
>D=48&-search" to url "http://##. ##. ##. #/FMP_MC/Action.lasso" (of course a
>real IP nbr goes where ##'s are)
>
>I can simply use
>
>  put  url
>"http://##. ##. ##.
>#/FMP_MC/action.lasso?-database=Students.fp3&-layout=Firs
>tStep&-response=Field:'gbRespOne'&-recordID=48&-search" into fld "report"
>
>with the same result.  Now, I haven't had the luxury yet of testing whether
>this improves on the percentage of unreturned calls, but the following issue
>comes up regardless:
>
>If I recall various sources of information correctly, Scott has suggested
>that MC is likely to lose the "post" command from the next
>version of MC in favor of socket-level coding.
>
>Scott -- is this correct?  If so, is the  "put url" also likely to go?  Is
>there a difference in how they work underneath?
>
>But more importantly.....
>because I only partly understand the mechanics of using  "sockets-level"
>programming for http, as opposed to post/put commands, I would like to offer
>the following question to the list  in hopes that you all can give me some
>more clues about "sockets."
>
>Q1) If it is the case that "post" is untrustworthy or about to become
>extinct, then what will be the "socket" equivalent of the
>following post command?

It's really not that scary. The higher level of control/monitoring over what is going 
on makes it worth learning. In your example you would do something like this:

open socket <xxx.xxx.xxx.xxx:80>  ##open connection to the server on port 80
write <stuff> to socket <xxx.xxx.xxx.xxx:80> ##write the POST stuff just like a 
browser would
read from socket <xxx.xxx.xxx.xxx:80> until eof  ## get the result from the server.
put it into var1 

A while back I answered a similar post with *real* examples, look through the archives 
for this month or the one before.
I would also suspect the other side - server+lasso. 
I would also try POSTing the whole header just like a browser would. 
There is a mac tool OTSessioWatcher by Stairways which allows you to follow what 
exactly is sent and received in a network communication which can show you what a 
browser sends and what the server replies.

>
>post
>"-Database=Students.fp3&-layout=LayoutNameHere&-Response=ResponseFileNameHer
>e&
>Social_Security=333444333&-search" to url "http://##. ##. ##.
>#/Action.lasso"
>
>This Post command will search for #333444333 in Social Security field in
>Students database and, through a response file,  return the student's first
>name,
>last name etc.
>
>>From a browser's perspective the HTML equivalent of post command above (in
>the form of the web link) will be:
>
> <A
>HREF="action.lasso?-database=Students.fp3&-layout=Details&-response=Studen
>tInfo.lasso&Social_Security=333444333&-search">Click this link to retrieve
>students Information</A>
>
>So, the number 1 Qustion really is what will be the "socket" equivalent of
>the following
>post command?
>
>post
>"-Database=Students.fp3&-layout=LayoutNameHere&-Response=ResponseFileNameHer
>e&
>Social_Security=333444333&-search" to url "http://##. ##. ##.
>#/Action.lasso"
>
>Q2 through 5)  Why are socket-level solutions, when finally written, likely
>to be more reliable?  Are they truly more flexible?  Why is the required
>"programmer's" knowledge load being moved from "built-in" to
>"build-your-own" with these improvements?  Will this level offer, for
>example, one to trap a failed return so a call can be reissued?  This is a
>complex mix of MC rules and http rules that I'm trying to get a handle on
>and somehow haven't yet fully grasped.   And I am willing to try to learn it
>if it really will solve my problem.  Where can I start?  I suspect we have a
>few really savvy internet MC  developers out there who can help, if not by
>explanations at least by offering working examples, and any help would be
>greatly appreciated, either on or off list.
>
>Thanks,
>Roger
>


Regards, Andu
__________________
[EMAIL PROTECTED]

Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.

Reply via email to