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 II
Goto page 1, 2, 3, 4  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: Fri Aug 06, 2004 11:30 am    Post subject: Kixforms Sockets : Discussion II Reply with quote

Will be posting a new build sometime today. Ran into a very curious issue that I had to resolve for Socket support.

Background:

Some of you may be aware that Kixforms can only handle ONE event at a time. Multiple events being triggered at once hardly ever happened in the past - so it wasn't an major issue. And when it did happen - it was an issue that I handled under-the-covers. An example of this might be a ListBox full of items. If you click on the listbox it might want to fire the Click event and the SelectedIndexChanged event at the same time - but currently - only one event can make it through, so I kinda ordered them by "priority".

Current:

Sockets are different and much more dynamic. I am currently writing a script that is both a ECHO client and server all in one (script). The problem i ran into was that when the script connected to itself, the OnConnect and OnAccept events where being triggered at the same time - and the OnConnect event would "win". Therefore the OnAccept was never being triggered.

Solution:

This is something I've been meaing to do for a while - sockets just sorta prompted me to actually do it. Kixforms now supports the queuing of socket events - so now all sockets event are triggered properly, and arrive in the order they were received - this is absolutely vital to the going-forward success of (not just sockets) but other things as well.

Anyways, will be posting a new build later and can discuss further.

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


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Fri Aug 06, 2004 11:32 am    Post subject: Reply with quote

This sounds like a great development. Does this apply to only sockets or to all other events as well?

I look forward to seeing the next version!

_________________
-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: Fri Aug 06, 2004 11:37 am    Post subject: Reply with quote

I wanted to go slow with this change, so right now it just applies to Sockets and only for the DoEvents method of the Form object. The System.Application.DoEvents hasn't been updated to support queued events yet.

When you see the script that I will post later-on - it will be obvious how important this is ... in fact, if you run the script your developing now, it might actually "break" something (in a good way) because other events might be getting through, that weren't before.

-Shawn
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: Fri Aug 06, 2004 12:49 pm    Post subject: Reply with quote

But it won't 'break' our old scripts ?

the good olde .DoEvents() and .DoEvents(1) will work the same in future releases ?

_________________
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: Fri Aug 06, 2004 12:51 pm    Post subject: Reply with quote

ja
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: Fri Aug 06, 2004 12:56 pm    Post subject: Reply with quote

the event names... totally unhappy with onAccept.
the name onAccept says that either we (the script or user) has accepted the connection or that the server we tried to contact accepted our connection attempt.

I catched shawn and what I understood neither of these are the case but onAccept is just translation of Accept.

looking at the winsock documentation, in blocking socket, one would call listen() and the listen will not return until connection request has arrived.

in non blocking, that would be something like, onArrival or onConnectionAttemp or onConnRequest.

I say this now as we are still running first builds with this.
the cry won't help when we have to have some sorta backwards compatibility with old builds.

also, shawn.
as we can't see the socket-object hierarchy nowhere, it would be great if you placed a short reference to your sample script.
would waste about 5 mins of your time (lot less than coding the script) and it would save hours of our time.
just bleeding here...

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


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Fri Aug 06, 2004 5:07 pm    Post subject: Reply with quote

Jooel - i appreciate the feedback and I want the feedback - i hate developing in a vacuum and all ideas are welcome. Folks shouldn't hesitant to voice their opinion - I urge them to.

Lets pick-up this discussion after the next build, after you see how all these pieces fit together, it may be pre-mature to talk until then - don't forget - this is all new stuff to me too. So lets work-out the best way together.
Back to top
View user's profile Send private message
Shawn
KiXforms Developer
KiXforms Developer


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Fri Aug 06, 2004 5:34 pm    Post subject: Reply with quote

ok - lesson learned - i've been chasing-around an Event bug for the past two hours ... ytf wasn't my OnDisconnect event being triggered (entered) as it should - my hard-learned lesson for today is:

If you have two functions with the exact same name in your script, the tiny stubbed-out one at the END of your script (that you forgot about) takes precedence over the one your hacking-away at, at the beginning of your script, trying to figure-out wtf is going-on ! :0) ... lol ....

Ruud should flag those ...

-Shawn


Last edited by Shawn on Fri Aug 06, 2004 5:41 pm; edited 1 time in total
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: Fri Aug 06, 2004 5:38 pm    Post subject: Reply with quote

that's a bug.
iirc, it complained about these before.

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


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Fri Aug 06, 2004 5:39 pm    Post subject: Reply with quote

ok, lets talk a little bit - and Ben kinda mentioned this before - if a server is listening for sockets, how does one "reject" a connection without first accepting it ? In order to figure who is calling you, you need to accept the connection, then query whatever, then choose to accept or reject. If you reject, should you then disconnect the link (but from the client's stand-point, you've already accepted it) ... hmmmm - must be an api we're missing here.
Back to top
View user's profile Send private message
Bonji
KiXforms Aficionado
KiXforms Aficionado


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Fri Aug 06, 2004 5:44 pm    Post subject: Reply with quote

Here is some info from SocketWrench's site on this exact issue...
Quote:

Summary
A user asks:
Why can't I view the PeerAddress or PeerName properties before I connect with someone? What if I don't want to connect to a certain address?


Status
The fundamental problem is that you don't have a valid socket until the point that you accept the connection, and there is no peer for the listening socket that is waiting for inbound clients to connect. This is simply the way that the Windows Sockets API works; you can only reference the PeerName and/or PeerAddress properties after the connection has completed (in the case of a server application, after the Accept property has been set). There is no way, using our control or the Windows Sockets API, to obtain the peer address of an incoming connection prior accepting that connection. Using an analogy, when the client calls on your server, your only option is to pickup the phone and after determining who it is, if you don't want to talk with them, you hang up. There is no "caller ID" in the standard Windows Sockets API which allows you to refuse a connection prior to accepting it. Microsoft does have a non-standard extension called AcceptEx which provides some of this functionality, but it is not supported at all under Windows 95/98, and we believe the ability to reject connections prior to accepting them is only available on Windows XP. In any case, because this function is non-standard, it is not used in SocketWrench.

As mentioned above, this is not possible because it's not how the Windows Sockets API is designed to work. Regardless of whether you use our control, another vendor's control or the Windows Sockets API directly, you'd run into exactly the same situation.


It sounds like you have to accept it first. If you have the luxury of writing the client, then you could send back predetermined control codes that the client could interpret in order to display the appropriate message to the user.

_________________
-Ben
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: Fri Aug 06, 2004 5:46 pm    Post subject: Reply with quote

well, accepting only accepts the socket to be "created"
connect is another function.
Quote:
Return Values
If no error occurs, accept returns a value of type SOCKET that is a descriptor for the new socket. This returned value is a handle for the socket on which the actual connection is made.


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


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Fri Aug 06, 2004 5:48 pm    Post subject: Reply with quote

I believe you are connected once the Accept event has been completed. Shawn can correct me if I'm wrong on this. Or anyone else for that matter. Wink
_________________
-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: Fri Aug 06, 2004 6:14 pm    Post subject: Reply with quote

I love this board - ok, the phone analogy makes sense and the SocketWrench folks recognise this as a socket protocol gap ... what I was doing (trying to do) was listen for a socket, accept it, then if I didn't want to accept issue a disconnect on the accepted socket - the client then sees this whole process as a quick connect then disconnect.
Back to top
View user's profile Send private message
Bonji
KiXforms Aficionado
KiXforms Aficionado


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Fri Aug 06, 2004 6:17 pm    Post subject: Reply with quote

Makes sense to me. I was looking at their site some more and they basically said that in order to reject an undesirable connection, you would have to accept, check the connection, then disconnect if unwanted. Which is exactly what you just said so it looks like a go.
_________________
-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 1, 2, 3, 4  Next
Page 1 of 4

 
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