[Implemented] Able to ignore #PB_NetworkEvent_File

[Rescator]

I can't find the post that mentioned this. (please post if any of you remember the thread I'm talking about)
But it was said that sending a networkfile to a server that is not expecting it might confuse the server or rather your program.

So I was thinking that it would make more sense to separate the send and receive and #PB_NetworkEvent_File stuff from the network lib.

So that if the ReceiveNetworkFile and SendNetworkFile are not used in the program then #PB_NetworkEvent_File would be ignored (or rather just treated as if it was #PB_NetworkEvent_Data)

Does that make any sense or?

[Joakim Christiansen]

Does that make any sense or?

Makes sense to me!
Maybe people could even cripple some PB made servers by using the SendNetworkFile function.

[helpy]

==> http://www.purebasic.fr/english/viewtop ... le#p328494

If the client is not allowed to send files to the server, the server could close the connection to the client. As soon as you get an #PB_NetworkEvent_FIle you can CloseNetworkConnection(EventClient()), because the client does not keep the "server rules".

You are writing the code of the server/client ... and you (the programmer) can determine which data your program should accept. Each program, which tries to connect to one of your programs over network tcp or udp, has to meet your "protocoll" (your specification of your client/server communication protocoll).

[Rescator]

Yeah, but what happens if a packet by random happens to have the "File" trigger in it, what happens then?
For example you are sending a datafile that by chance have the magic id at the start of the packet,
that would create a false #PB_NetworkEvent_File event or?

Maybe Fred or Freak can shed some light on this; and maybe that is something that could never happen the way it's implemented. (anyone tested that scenario yet?)

But personally I'd be ok with even a directive like: DisableNetworkFile
But I also think that it could also be done automatically as suggested in my first post here.

After all it would be silly if it's necessary to escape the magic 'PBMGSFLE' bytes from all initial packets right?


Now if it's possible to use ReceiveNetworkData() even if you got a #PB_NetworkEvent_File event then this is a non-issue as you could just do:
Result = NetworkServerEvent()
If Result=#PB_NetworkEvent_Data Or Result=#PB_NetworkEvent_File
;process the data.
EndIf
Though it kinda irks the programmer in me to do a (in this case wasteful) " Or Result=#PB_NetworkEvent_File".

[helpy]

Now if it's possible to use ReceiveNetworkData() even if you got a #PB_NetworkEvent_File event then this is a non-issue as you could just do:
Result = NetworkServerEvent()
If Result=#PB_NetworkEvent_Data Or Result=#PB_NetworkEvent_File
;process the data.
EndIf
Though it kinda irks the programmer in me to do a (in this case wasteful) " Or Result=#PB_NetworkEvent_File".

This works! I tried it.

cu, guido

[Rescator]

Hmm. I read your post in that thread helpy, so you can use receivedata even on a file event?
In that case this should work. (but Fred would have to freeze the constant forever if the following is to work though)

Code: Select all

event=#PB_NetworkEvent_File

If event&#PB_NetworkEvent_Data
	Debug "Data or File event"
EndIf

This will currently work due to the bit mask of #PB_NetworkEvent_Data which is 10
and #PB_NetworkEvent_File which is 11

"If event&#PB_NetworkEvent_Data" will be true if bit 1 is set, which it is for both events.
This obviously means that any future events that are added can never set bit 1 or this could break.
(like event 6, or 7 or 10 etc.)

Is this a possibility Fred, that only the Data and File events will ever set bit 1 ?

[Rescator]

Actually that may be possible Fred, as the constants could be done this way:
#PB_NetworkEvent_None=$0
#PB_NetworkEvent_Connect=$1 ;%00001
#PB_NetworkEvent_Data=$2 ;%00010
#PB_NetworkEvent_File=$3 ;%00011
#PB_NetworkEvent_Disconnect=$4 ;%00100
#PB_NetworkEvent_FutureEvent=$8 ;%01000
#PB_NetworkEvent_AnotherEvent=$10 ;%10000

This way all constants except for Data and File will have typical bitflag behavior.
The downside obviously is that this limits the max flags to 32 in this case, but that is hopefully enough for future use.
Then again one could always let other flags or constants share certain bits as well, not sure what to call that really but...either way works.