KiXforms Forum Index KiXforms
The Forum for the KiXforms Community
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 Quick Links 
Site News
Downloads
Documentation
Donations
Script Archive
Tracking Systems

Kixforms Sockets : Discussion
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    KiXforms Forum Index -> Discussion
View previous topic :: View next topic  
Author Message
Shawn
KiXforms Developer
KiXforms Developer


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Wed Aug 04, 2004 12:28 pm    Post subject: Reply with quote

hmmm, i would have though blocking to be the easiest and most used mode myself. whats the SocketWrench default ?

here's the blocking version of SocketListener - can't use the GUI because it blocks .... which is an interesting problem ... hmmmm

Code:

break on

;
; ECHO SERVER (LISTENER)
;

$ADDRESS = "127.0.0.1"
$PORT = 777
$MAXCLIENTS = 5

$system = createobject("kixtart.system")

$listener = $system.socket()

$listener.address = $ADDRESS
$listener.port = $PORT
$listener.bind()
$listener.listen()

while 1

 $socket = $listener.accept()

 $text = $socket.receive()

 while $text

  $socket.send($text)

  $text = $socket.receive()

 loop

loop

exit 0


Last edited by Shawn on Wed Aug 04, 2004 12:30 pm; edited 1 time in total
Back to top
View user's profile Send private message
Bonji
KiXforms Aficionado
KiXforms Aficionado


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Wed Aug 04, 2004 12:29 pm    Post subject: Reply with quote

I could very well be mistaken, as I'm going with what I do myself. Ultimately, I'm fine either way as long as I know which it is.

I'll check on SocketWrench...

_________________
-Ben


Last edited by Bonji on Wed Aug 04, 2004 12:29 pm; edited 1 time in total
Back to top
View user's profile Send private message
Chris S.
KiXforms Enthusiast
KiXforms Enthusiast


Joined: 05 Mar 2003
Posts: 241

PostPosted: Wed Aug 04, 2004 12:29 pm    Post subject: Reply with quote

Shawn wrote:
SocketWrench uses the method return value to gives errors.


With most of the COM object I've worked with this has been the defacto method for returning error codes. I'd vote for this method as well.
Back to top
View user's profile Send private message MSN Messenger
Bonji
KiXforms Aficionado
KiXforms Aficionado


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Wed Aug 04, 2004 12:31 pm    Post subject: Reply with quote

Here's an excerpt from their documentation...
Quote:

One of the first issues that you’ll encounter when developing your Windows Sockets applications is the difference between blocking and non-blocking sockets. Whenever you perform some operation on a socket, it may not be able to complete immediately and return control back to your program. For example, a read on a socket cannot complete until some data has been sent by the remote host. If there is no data waiting to be read, one of two things can happen: the function can wait until some data has been written on the socket, or it can return immediately with an error that indicates that there is no data to be read.

The first case is called a blocking socket. In other words, the program is "blocked" until the request for data has been satisfied. When the remote system does write some data on the socket, the read operation will complete and execution of the program will resume. The second case is called a non-blocking socket, and requires that the application recognize the error condition and handle the situation appropriately. Programs that use non-blocking sockets typically use one of two methods when sending and receiving data. The first method, called polling, is when the program periodically attempts to read or write data from the socket (typically using a timer). The second, and preferred method, is to use what is called asynchronous notification. This means that the program is notified whenever a socket event takes place, and in turn can respond to that event. For example, if the remote program writes some data to the socket, a "read event" is generated so that program knows it can read the data from the socket at that point.

For historical reasons, the default behavior is for socket functions to "block" and not return until the operation has completed. However, blocking sockets in Windows can introduce some special problems. For 16-bit applications, the blocking function will enter what is called a "message loop" where it continues to process messages sent to it by Windows and other applications. Since messages are being processed, this means that the program can be re-entered at a different point with the blocked operation parked on the program's stack. For example, consider a program that attempts to read some data from the socket when a button is pressed. Because no data has been written yet, it blocks and the program goes into a message loop. The user then presses a different button, which causes code to be executed, which in turn attempts to read data from the socket, and so on.

Blocking socket functions can introduce a different type of problem in 32-bit applications because blocking functions will prevent the calling thread from processing any messages sent to it. Since many applications are single-threaded, this can result in the application being unresponsive to user actions. To resolve the general problems with blocking sockets, the Windows Sockets standard states that there may only be one outstanding blocked call per thread of execution. This means that 16-bit applications that are re-entered (as in the example above) will encounter errors whenever they try to take some action while a blocking function is already in progress. With 32-bit programs, the creation of worker threads to perform blocking socket operations is a common approach, although it introduces additional complexity into the application.

It should be noted that there are advantages to using blocking sockets. In most cases, the application design and implementation is simpler, and raw throughput (the rate at which data is sent and received) is generally higher with blocking sockets because it does not have to go through an event mechanism to notify the application of a change in status. In general, if your application is designed as a client, and does not have the need to establish multiple simultaneous connections then blocking sockets may be appropriate. However, if your application functions as a server or needs to establish multiple connections then an asynchronous, event-driven design is more appropriate.



This may be helpful to designers and users alike.

_________________
-Ben
Back to top
View user's profile Send private message
Bonji
KiXforms Aficionado
KiXforms Aficionado


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Wed Aug 04, 2004 12:44 pm    Post subject: Reply with quote

The pausing of the GUI is the biggest problem I run into with blocking sockets, and is why I try to avoid them.
_________________
-Ben
Back to top
View user's profile Send private message
Shawn
KiXforms Developer
KiXforms Developer


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Wed Aug 04, 2004 12:50 pm    Post subject: Reply with quote

ja, plus a listener that uses blocking sockets can only support one connection I would imagine. The problem cited in the SocketWrench doc, about re-entrent code with blocking sockets wouldn't (couldn't) apply to Kixtart. But it could be an issue with non-blocking sockets and client code (thats why on the SocketCommander code, i purposely disabled the CONNECT button once a connection was made, don't want the user to be able to reconnect a connected socket).

The other thing is - is it possible for a client code to want to BIND to a local address on an outgoing socket ? Thus the need to break-out the ADDRESS properties into LOCALADDRESS and REMOTEADDRESS ?

-Shawn
Back to top
View user's profile Send private message
Lonkero
KiXforms Devotee
KiXforms Devotee


Joined: 13 Mar 2003
Posts: 1022
Location: Espoo, Finland

PostPosted: Wed Aug 04, 2004 12:54 pm    Post subject: Reply with quote

that's why some of us use multi-process scripts.
the blocking mode is most reliable and even though it eats memory almost twice as much (due to double wkix32.exe) it eats lots less brainpower and in many situations cpu.

to keep your gui responsive, you can't go up from refresh interval of 0.02 secs.
then, if you have heavy code, you end up messing up your head trying to keep it running.

simple example is bbchecker, trying to keep it unblocking while retrieving page info and probably at the same time update the gui with new info and still keep it responsive for user to click around and post PMs and stuff...

anyway, what the default is probably does not matter.
one needs to suite it for each need separately anyways.

_________________
Hammer
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Jochen
KiXforms Devotee
KiXforms Devotee


Joined: 05 Mar 2003
Posts: 1204
Location: Stuttgart, Germany

PostPosted: Wed Aug 04, 2004 1:01 pm    Post subject: Reply with quote

Blocking? Non-blocking ?

Excuse me stupidity, but all I can imagine reading this a blocked (read locked) socket Stupid

It has more likely to do with Blocks (like something bundled) , no ? Embarassed

[edit : forget this stupid question, there was a perfect explanation earlier in this thread ... it did last quite a while from 'Reply' to 'Submit' Rolling Eyes ]

_________________
Jochen

Tell me, and I will forget.
Show me, and I may remember.
Involve me, and I will understand.
Back to top
View user's profile Send private message MSN Messenger
Shawn
KiXforms Developer
KiXforms Developer


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Wed Aug 04, 2004 1:05 pm    Post subject: Reply with quote

ja, i think i will make blocking the default mode, because most client code would probably use blocking mode (its easier to understand) and most server code would use non-blocking (to support multiple connections and asynchronous events from many clients).

To help the client with a GUI though, will try to implement the TIMEOUT property so that the GUI doesn't block for too long. And for server code, just have to set the Socket.Blocking = 0 to enable non-blocking mode.
Back to top
View user's profile Send private message
Jochen
KiXforms Devotee
KiXforms Devotee


Joined: 05 Mar 2003
Posts: 1204
Location: Stuttgart, Germany

PostPosted: Wed Aug 04, 2004 1:08 pm    Post subject: Reply with quote

I can't wait to totally rewrite hearts (again) ya know Mr. Green
_________________
Jochen

Tell me, and I will forget.
Show me, and I may remember.
Involve me, and I will understand.
Back to top
View user's profile Send private message MSN Messenger
Les
KiXforms Aficionado
KiXforms Aficionado


Joined: 24 Dec 2003
Posts: 317

PostPosted: Wed Aug 04, 2004 1:19 pm    Post subject: Reply with quote

I can see it now... J rewriting games to be network multi-player. Very Happy
_________________
The Repro Man
Stealing for a living!
Back to top
View user's profile Send private message
Shawn
KiXforms Developer
KiXforms Developer


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Wed Aug 04, 2004 1:28 pm    Post subject: Reply with quote

captain has this "thing" about multi-player network games - he's done it in the past, without using sockets.

Ben - btw, just because I'm proposing to make blocking the default mode doesn't mean i "like" blocking mode - in fact, i think non-blocking is the way to go. just that think it might make more sense as the default. and that one would have to get into non-blocking mode "on purpose" which means one knows what their doing, and knows how to code a non-blocking script.
Back to top
View user's profile Send private message
Bonji
KiXforms Aficionado
KiXforms Aficionado


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Wed Aug 04, 2004 1:31 pm    Post subject: Reply with quote

Sounds good to me! Very Happy
_________________
-Ben
Back to top
View user's profile Send private message
Jochen
KiXforms Devotee
KiXforms Devotee


Joined: 05 Mar 2003
Posts: 1204
Location: Stuttgart, Germany

PostPosted: Wed Aug 04, 2004 1:37 pm    Post subject: Reply with quote

Les wrote:
I can see it now... J rewriting games to be network multi-player. Very Happy


Yeah, hearts was my first and only functioning Kixbgi32 4 player game doing communications through an ini file...

_________________
Jochen

Tell me, and I will forget.
Show me, and I may remember.
Involve me, and I will understand.
Back to top
View user's profile Send private message MSN Messenger
Bonji
KiXforms Aficionado
KiXforms Aficionado


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Wed Aug 04, 2004 1:57 pm    Post subject: Reply with quote

My IM program does communications through ini files and standard file operations. It is cumbersome, but gets the job done. I've already started writing a new IM server that uses sockets, and it is so much simpler.
_________________
-Ben
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    KiXforms Forum Index -> Discussion All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 2 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group