Socket Accept/Connection Question/Problem

Jim Ault JimAultWins at yahoo.com
Thu Feb 28 12:41:47 CST 2008


He used to have both protocols up there.
The key difference is
datagram, I think

Jim Ault
Las Vegas


On 2/28/08 10:36 AM, "Dave" <dave at looktowindward.com> wrote:

> Hi Jim,
> 
> I will take a look, but these use UDP, I am not using UDP, I need to
> use straight TCP/IP.
> 
> All the Best
> Dave
> 
> 
> On 28 Feb 2008, at 18:20, Jim Ault wrote:
> 
>> Go to user spaces in Rev online
>> alexTweedly
>> sample stacks as
>> Echo client
>> Echo server
>> 
>> These will run and show what an expert in the network field has
>> done for
>> good sample stacks.
>> 
>> It is what I used to get started.
>> 
>> Jim Ault
>> Las Vegas
>> 
>> 
>> On 2/28/08 10:13 AM, "Dave" <dave at looktowindward.com> wrote:
>> 
>>> 
>>> On 28 Feb 2008, at 17:50, Jim Ault wrote:
>>> 
>>>> 
>>>> On 2/28/08 8:35 AM, "Dave" <dave at looktowindward.com> wrote:
>>>> 
>>>>> 
>>>>> On 28 Feb 2008, at 16:10, Troy Rollins wrote:
>>>>> 
>>>>>> 
>>>>>> On Feb 28, 2008, at 9:54 AM, Dave wrote:
>>>>>> 
>>>>>>> Statement should call "ClientSocketOpen" if the Server accepted
>>>>>>> the connection or call "socketError" or "socketTimeout" if there
>>>>>>> was an error? e.g. the Server closed the socket?
>>>>>> 
>>>>>> FWIW, I'm finding the whole "state of sockets" to be a bit of a
>>>>>> conundrum as well. In my case, the client is not Rev, and it does
>>>>>> indicate once a socket connection is made. However, Rev is acting
>>>>>> as the server, and it seems hit or miss on determining if the
>>>>>> client has disconnected.
>>>>> 
>>>>> Great. It seems like a lot of RunRev, just bearly working if you
>>>>> know
>>>>> *exactly* what to do and with no documentation and no support from
>>>>> RunRev themselves, the whole experience one of frustration and
>>>>> suck-
>>>>> it-and-see mentality.
>>>> 
>>>> Actually, sockets are controlled by the operating system, so there
>>>> are wide
>>>> variations, even within XP.  Firewall hardware and software,
>>>> routers, hubs,
>>>> ISP protocols, and other device performance.
>>> 
>>> I am only using Mac OS X at the moment.
>>> 
>>>> To build a solid networking app you need to learn a lot about the
>>>> world of
>>>> protocols and idiosyncrasies, regardless of the programming
>>>> language.
>>> 
>>> Well, I trying to use RunRev, I can communicate using other languages
>>> ok. It's really the lack of any decent documentation or a robust
>>> sample app that shows what you need to tweak in order to make it work
>>> in the real world.
>>> 
>>>> Rev has the tools and functions to build this, but you have to tune
>>>> it to
>>>> your equipment and configurations.
>>> 
>>> That's what I mean, there is no documentation that I can find that
>>> shows how to do this. I've found some sample code that was useful to
>>> get going, but it's not well documented and it isn't really "real-
>>> life".
>>> 
>>>> tip:  If your are using UDP and MacOSX, and testing for max packet
>>>> size your
>>>> equipment will allow, be sure to
>>>> go to system prefences:network:ethernet
>>>> change from automatic to manual
>>>> then set your max packet size to jumbo vs 1500 default
>>>> 
>>>> Otherwise, OSX will receive larger packets but not pass them to
>>>> your Rev
>>>> app.  This will be a silent failure and undertectable without an
>>>> ACKNOWLEDGE
>>>> loop that you would build.
>>> 
>>> I am sending very small packets at the moment, maybe 30 characters
>>> max. If and when I get this bit working it will send larger packets,
>>> but the maximum will still be less that 2K.
>>> 
>>>> By the way, I routinely build an ACK loop between my apps since
>>>> networks are
>>>> good at providing surprises.
>>> 
>>> Not much help here, I can't do an NAK because the server is not
>>> supposed to respond to a Client that isn't in the "Allowed" list.
>>> 
>>> Thanks a lot
>>> All the Best
>>> Dave
>>> 
>>> 
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription
>>> preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>> 
>> 
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>> 
> 
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution





More information about the use-livecode mailing list